Profit - High Tech

Sogeti Pays-Bas Martin van den Berg
Sogeti USA Erik van Ommeren
IBM Software Group Allemagne Norbert Bieberstein
Une contribution pratique et
pragmatique à l'évolution de la
SOA en tant qu'approche architecturale créatrice de valeur pour
l'entreprise. Les différentes visions et les considérations informatiques complètes établies concernant la SOA s'appuient sur
des exemples réels et convaincants. Ce document constitue un
guide prêt à l'emploi pour adopter et mettre en œuvre une SOA.
C’est un document de référence
exceptionnel pour toute personne désirant passer à un niveau supérieur d’alignement de
l’informatique d’entreprise et du
métier grâce à la SOA.
Henrik Jacobsson
Shell
Mon intérêt n’a cessé de croître
au fur et à mesure de ma lecture
du manuscrit… conclusion : «ça
valait le coup» ! L’approche
business, utilisateurs et organisation que les auteurs ont
privilégiée est très pertinente.
Malgré le luxe de détails on n’est
pas submergé de considérations
techniques : un des gros avantages de ce livre ! Un modèle et
une méthode pratiques de mesure de la maturité sont présentés, et la liste finale de références
est très complète et à jour. Si
vous voulez savoir pourquoi je
préfère la définition Bieberstein
de la SOA, lisez le livre par vousmême. En ce qui me concerne,
aucun regret…
Dr. Jan Peter de Valk
ING
SOA
Guide du manager pour une Architecture Orientée Services réussie
L’architecture orientée services (SOA) est en train de devenir
l’architecture informatique dominante, ce qui a des implications
considérables pour le fonctionnement des organisations.
Lentement mais sûrement, l’informatique gagne en maturité et
devient ce support à la fois flexible, stable et fiable dont toute
entreprise a besoin. Dans le même temps, l’informatique revient
en force dans les processus d’innovation au sein de l’entreprise.
Pour toute organisation, la SOA constitue à cet égard un pas
décisif dans la bonne direction à condition de ne pas en faire
une simple question de technologie. Bien sûr, les défis
technologiques sont importants à relever, mais l’apport
essentiel de la SOA se situe ailleurs : une prise en compte
globale de la façon dont l’informatique peut devenir l’élément
clé du succès de toute stratégie d’entreprise.
SOA for Profit dévoile la nature de la SOA et illustre la valeur
ajoutée qu’elle apporte. Cet ouvrage pratique et pragmatique
rend les modèles et les concepts de la SOA intelligibles grâce à
une approche clé en main directement applicable avec profit à
vos projets. Il met en avant l'importance de la gouvernance et
de l'architecture informatiques et démontre qu'une vision
élargie de la SOA est essentielle pour en tirer tous les bénéfices
possibles. Ce livre raccroche l'informatique au management
grâce à des outils et à un langage communs qui rendent
possible le dialogue stratégique que l'on retrouve à la base de
toute informatique orientée métiers.
Écrit par une équipe d'auteurs de Sogeti et d'IBM, SOA for
Profit est un livre concret, tiré d'une longue expérience
d'entreprises et de projets bien réels.
SOA for Profit
Yves Caseau
Bouygues Telecom
SOA for Profit
for Profit
Avec les contributions de
Per Björkegren Sogeti Suède •
Jean-Marc Gaultier Sogeti USA •
Lon Holden IBM Software Group
USA • Manuel de Juan Sogeti
Espagne • Tim Koomen Sogeti
Pays-Bas • Craig Mayer Sogeti USA
• Philippe Ravix Sogeti France •
Bruno Rizzi Sogeti France •
Gonzalo Rodriguez Sogeti
Espagne • Guillaume Schott Sogeti
Belux • Gerard Smit IBM Pays-Bas •
Michiel Vroon Sogeti Pays-Bas
Van den Berg
Van Ommeren (dir.)
Bieberstein
Ce livre est sans conteste le
meilleur livre que j’aie lu sur la
SOA. C’est un livre concret, qui
traite et relie les différents
aspects de cette approche SOA,
depuis la stratégie et les enjeux
métiers jusqu’à la conduite du
changement et des rôles des collaborateurs. Les chapitres sur la
gouvernance et sur préparation
sont eux aussi les meilleures
contributions que je connaisse
sur ces sujets, avec un équilibre
entre l’explication (en donnant
du sens) et l’application (en restant concret et synthétique).
Contribution majeure qui devrait
être lue par tous les managers
non-informaticiens, ce livre permet de comprendre pourquoi la
SOA est fondamentalement
adaptée aux mutations des
entreprises d’aujourd’hui à condition de faire profondément
évoluer leur façon de travailler.
Le style est franc et direct, avec
une pointe d’humour, ce qui en
fait une lecture agréable.
Guide du manager pour une
Architecture Orientée Services réussie
SOA for Profit
Guide du manager
pour une SOA réussie
Martin van den Berg
Norbert Bieberstein
Erik van Ommeren
Contributeurs
Per Björkegren, Sogeti Suède
Jean-Marc Gaultier, Sogeti USA
Lon Holden, IBM Software Group USA
Manuel de Juan, Sogeti Espagne
Tim Koomen, Sogeti Pays-Bas
Craig Mayer, Sogeti USA
Philippe Ravix, Sogeti France
Bruno Rizzi, Sogeti France
Gonzalo Rodriguez, Sogeti Espagne
Guillaume Schott, Sogeti Belux
Gerard Smit, IBM Pays-Bas
Michiel Vroon, Sogeti Pays-Bas
2007, IBM et Sogeti
Cette création est mise à disposition selon le Contrat Paternité
3.0 France disponible en ligne http://creativecommons.org/
licenses/by-sa/3.0/deed.fr ou par courrier postal à Creative
Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.
http://creativecommons.org/licenses/by-sa/3.0/deed.fr
Les auteurs et éditeurs ont apporté tout leur soin à la fabrication de cet ouvrage mais refusent toute garantie expresse ou
implicite et déclinent toute responsabilité en cas d’erreur ou
d’omission. Aucune responsabilité n’est assumée pour les dommages indirects ou imprévus occasionnés par l’usage des informations ou programmes contenus dans cet ouvrage.
Les termes suivants sont des marques déposées d’International
Business Machines Corporations aux États-Unis d’Amérique et
dans les autres pays : Component Business Model et IBM. DYA
et TMap sont des marques déposées de Sogeti Netherlands bv
aux États-Unis d’Amérique et dans les autres pays.
Les opinions exprimées dans cet ouvrage le sont à titre collectif
par l’ensemble des auteurs et ne sauraient constituer la position officielle des entreprises qui les emploient.
2007 IBM et Sogeti
Traduction : AAAPrésentations
Production : LINE UP boek en media bv, Groningen, Pays-Bas
Design de couverture : Jan Faber
Photo de couverture :Plafond de boutique (Paris), par Claudia Meyer (www.sxc.hu)
Impression : Bariet, Ruinen, Pays-Bas
Reliure : Abbringh, Groningen, Pays-Bas
ISBN : 978-90-75414-18-9
Accueil positif de SOA for Profit
La plupart des ouvrages actuels traitant de l’architecture orientée services
expliquent dans les moindres détails les rouages des services Internet et
XML. Malgré toute l’importance de ces aspects, ces ouvrages négligent la
caractéristique essentielle de l’orientation services, à savoir qu’il s’agit d’une
démarche consistant en un alignement entre le métier et l’informatique, susceptible d’entraîner une réduction des coûts et une plus grande souplesse. Le
présent ouvrage se concentre sur cet aspect central que représente l’orientation services. Il traite de sujets importants tels que la maturité des services,
les étapes pratiques pour l’introduction de la SOA, la gouvernance de services
et l’architecture d’entreprise pour la SOA. Il explique parfaitement aux managers, dans des termes clairs et non techniques, ce que la SOA peut apporter à
l’entreprise.
Prof. Dr. Roel Wieringa,
Université de Twente
Une contribution pratique et pragmatique à l’évolution de la SOA en tant
qu’approche architecturale pour créer de la valeur pour l’entreprise. Les différentes approches et analyses globales de la SOA s’appuient sur des exemples réels et convaincants. Ce document constitue un guide prêt à l’emploi
pour adopter et mettre en œuvre une SOA. C’est un document de référence
exceptionnel pour toute personne désirant passer à un niveau supérieur d’activité et d’alignement informatique, grâce à la SOA.
Henrik Jacobsson,
Architecte informatique en chef, Shell
Il est particulièrement difficile pour les architectes informatiques de répondre
aux questions « quand », « comment » et « quoi » communiquer sur la SOA
aux managers et analystes. Cet ouvrage y contribue activement en fournissant
les éléments essentiels de l’orientation services de façon abordable et non
technique. Il sera très précieux, notamment pour un lectorat orienté
métiers.
David Sprott,
Forum CBDI
SOA for Profit explique aux managers et aux décideurs les possibilités ouvertes par l’utilisation de la SOA pour organiser et diriger son entreprise de façon
plus structurée. L’impact de l’application de la SOA est tel sur la culture de
l’entreprise que ce sont les performances et les bénéfices qui s’en ressentent
en dernier lieu.
Prof. Thomas Obermeier,
Directeur adjoint de la Fachhochschule der Deutschen Wirtschaft (FHDW), Bergisch-Gladbach, Allemagne
Aujourd’hui tout le monde parle de la SOA et il est aisé de l’écarter d’un
revers de main sous prétexte que ça ne serait qu’un effet de mode. En réalité,
c’est une façon totalement nouvelle de gérer l’informatique d’entreprise en
interne et, surtout, c’est un catalyseur informatique de changement au sein
de l’entreprise. Ce livre est le meilleur que j’aie lu sur le sujet : c’est tout un
art de toucher un public plus large et cet ouvrage en est une excellente illustration.
Ingvar Persson,
Responsable informatique, Iggesund
Un guide exaustif et complet qui traite en profondeur de tous les aspects
essentiels à la lumière des meilleures pratiques et des expériences disponibles aujourd’hui. Un point de départ solide pour toute organisation qui ne voit
pas dans la SOA un simple effet de mode, mais souhaite s’engager dans une
conversion durable à la SOA. Non pas SOA pour les nuls ! mais SOA pour les
pros ! Lisez par vous-même, vous verrez !
Menno Bosman,
Responsable communication, Fortis Insurance, Pays-Bas
Il y a beaucoup de bruit autour de la SOA en ce moment, mais la question est
de savoir si l’on parle d’effet de mode ou d’espoir. Ce regain d’intérêt vient
peut-être du côté de l’offre, des fournisseurs de logiciels et des consultants,
qui sont en train de se réveiller. Ce livre sur la SOA ne contient ni constats
naïfs sur les business processes, ni quintessence sur le middleware, ni jargon
d’intégristes de la SOA. Mais oui, c’est bien un livre sur la SOA. Par chance, il
traite des bénéfices qu’il y a à retirer de l’architecture et de la signification de
la gouvernance. Il est équilibré, compréhensible et contient juste ce qu’il faut
de précision.
Beaucoup de choses ont été écrites sur la SOA. Ce livre synthétise toute cette
information et la remet en perspective : comment obtenir de la valeur ajoutée
en ayant recours à la SOA ? Je le recommande chaudement à la fois aux
managers et aux étudiants.
Jan Truijens,
Maître de conférences en sciences commerciales et gestion de l’information,
Université d’Amsterdam
Les auteurs ont regroupé un grand nombre d’expériences bien réelles de la
SOA dans ce livre. Pour dégager de façon durable une valeur commerciale à
partir d’un projet de SOA, il faut beaucoup plus que la simple manipulation
de quelques outils technologiques, et ce livre offre des conseils pratiques qui
n’ont pas de prix sur les changements à anticiper et susciter dans votre organisation et votre culture d’entreprise pour réussir.
Neil Ward-Dutton,
Directeur de recherche, Macehitter Ward-Dutton
Après avoir publié DYA, Sogeti réussit une fois de plus à offrir à la communauté des architectes un nouveau point de vue, cette fois-ci sur la SOA.
L’orientation services est inévitable pour les organisations en réseau modernes, et l’architecture elle-même est ce qui fait toute la valeur de la SOA. Ce
livre en offre une large description qui va de l’identification des services dans
votre entreprise à la gestion du facteur humain. Surtout, il offre des conseils
concrets sur la gouvernance et sur les actions les plus basiques à mener et à
éviter.
Arjan Bulthuis,
Ministère de l’Agriculture, de la Nature et de la Qualité alimentaire des Pays-Bas
Mon intérêt n’a cessé de croître au fur et à mesure de ma lecture du manuscrit
au gré de mes voyages autour du monde. Conclusion : « ça valait le coup ! »
Même si la table des matières semblait un peu surchargée au premier abord,
les chapitres intitulés « J’en veux pour mon argent », « Sept concepts de
base », « Comment arriver à bon port » et surtout « Les dix meilleures choses
à dire pour se faire renvoyer » m’ont immédiatement attiré et se sont encore
avérés enrichissants à la seconde lecture. Le choix de privilégier une approche business, utilisateurs et organisation est très pertinent et le luxe de détail
est d’autant plus bienvenu qu’on n’est pas submergé de considérations techniques (un des gros avantages de ce livre !). Un modèle et une méthode
­pratiques de mesure de la maturité sont présentés et la liste finale de références est très complète et, encore plus important, à jour. Si vous voulez savoir
pourquoi je préfère la définition Bieberstein de la SOA, lisez le livre par vousmême. En ce qui me concerne, aucun regret…
Dr. Jan Peter de Valk,
ING
Ce livre constitue une introduction à la SOA pour les managers comme pour
les responsables informatiques. Il explique et rappelle utilement les concepts
de base de l’architecture orientée services (SOA) dont les professionnels de
l’informatique sont sans doute déjà familiers. Tout au long des développements, on voit comment, au fur et à mesure que des standards se sont développés et diffusés à une échelle sectorielle, la technologie a elle aussi gagné
en maturité, de telle sorte qu’aujourd’hui les outils, technologies, méthodologies et retours d’expérience sont disponibles pour pondérer les risques induits
par l’adoption de la SOA. Ce livre permet de démystifier la SOA et appuie ses
considérations théoriques d’exemples concrets qui tracent un chemin pratique pour la conduite réussie de projets de SOA.
Garry Gomersall,
Apôtre de la SOA et dirigeant d’entreprise, IBM Software Group
Avant-propos d’IBM
Fort de plus de trente ans d’expérience dans ce secteur, et notamment chez
IBM, j’ai joué un rôle actif dans les innovations qui ont constitué notre essence
même, qui nous ont permis de repousser nos limites et nous ont largement
appris l’incidence de la technologie sur la façon de mener une activité commerciale. Alors que nombreux sont ceux qui désigneraient l’ordinateur central, l’eBusiness ou les standards ouverts comme points d’inflexion ayant
modifié de façon spectaculaire notre fonctionnement en tant que départements et entreprises, le changement global le plus fondamental dans le
domaine informatique et commercial est incontestablement l’avènement de
l’architecture orientée services (SOA).
Je pèse tout le poids de cette affirmation et suis conscient de la pérennité de
cet ouvrage ; c’est la raison pour laquelle je réitère avec assurance que la SOA
a définitivement changé la façon de développer l’activité d’une entreprise. En
outre, en tant qu’experts en technologies et chefs d’entreprise, il nous reste à
exploiter pleinement les effets positifs et permanents qu’exerce et exercera
la SOA sur des entreprises de tailles diverses.
Nouvelle donne, innovation, préservation de l’existant. Je suppose qu’en relisant d’anciens rapports d’analystes et des articles de magasines spécialisés,
vous y trouverez le refrain habituel incitant à utiliser telle ou telle technologie.
Ne confondez pas la SOA avec ces tendances passées.
Bien que des entreprises s’appuient encore aujourd’hui sur plusieurs de ces
tendances, celles-ci étaient trop souvent divisées en catégories telles que le
matériel informatique, les logiciels ou les services puis subdivisées à nouveau ; l’objectif étant que chaque département au sein de l’équipe informatique au sens large sache qui est responsable de telle ou telle tâche, une fois
ces tendances déployées dans l’infrastructure. Cette approche semblait logique autrefois. Mais, dans une économie mondialisée qui dépend de plus en
plus de la relation symbiotique entre technologie et business, nous ne pouvons plus considérer l’entreprise et l’infrastructure de support de façon isolée.
C’est précisément sur ce point que la SOA se montre la plus précieuse. Cette
approche concerne l’ensemble de l’entreprise et livre, à la demande, les informations les plus pertinentes aux entreprises ou aux utilisateurs des systèmes
d’informations, indépendamment du lieu où se trouvent l’employé, le client
ou le partenaire, voire la source de l’information.
De nombreux analystes, clients et directeurs des systèmes d’information
avancent une multitude d’anecdotes pour justifier l’affirmation selon laquelle
la SOA représente la fusion la plus puissante de l’informatique et du business
pour permettre la progression des entreprises. Pour ôter toute ambiguïté,
laissez-moi partager avec vous trois principes expliquant pourquoi la SOA
n’est pas l’outil révolutionnaire de demain mais plutôt une stratégie destinée
à aligner plus étroitement la technologie et les objectifs de l’entreprise. Grâce
à cette stratégie, ces dernières peuvent accroître leur productivité et leurs
résultats.
Premièrement, la SOA est une façon de développer son business. Les entreprises et les technologies sur lesquelles elles s’appuient peuvent fluctuer sans
cesse, mais la SOA est une stratégie éprouvée qui assure que toutes les parties
de l’entreprise peuvent se recouper librement et simplement, et communiquer pour maximiser la productivité tout en mettant l’accent sur les besoins
du client. Ceci m’amène à mon deuxième point.
La SOA favorise l’innovation. Lorsque les employés, les clients et les partenaires peuvent partager les informations et les idées sans être gênés par les
limites des silos ou des applications propriétaires, cela se traduit par des
approches métier innovantes. Ces innovations vont des processus de streamlining à une collaboration mondiale en passant par des inventions capitales.
Troisièmement, la SOA utilise et réutilise la connaissance, les atouts et les
investissements déjà existants. Dans certaines entreprises, le terme SOA reste
relégué à l’arrière-plan et certaines personnes se creusent encore la tête pour
essayer de comprendre ce que signifie cette nouvelle abréviation. Pour ceux
qui sont au courant, le point positif est que la SOA tire profit des sources
existantes d’information et d’investissements en matière de technologie et
permet aux entreprises de les réutiliser sans compromettre l’intégrité des
fonctions existantes. C’est bien là la garantie que la SOA est un investissement
rentable qui ne nécessite pas de longues formations.
Au cours de votre lecture, vous comprendrez mieux les conséquences et les
implications de la SOA sur les entreprises de toutes tailles. Vous comprendrez
aussi que tous les discours concernant l’outil révolutionnaire de demain
n’étaient en fait que les prémices de l’arrivée de la SOA. Alors préparez-vous,
asseyez-vous confortablement et laissez-vous guider, car la SOA n’est pas
prête de disparaître.
Steve Mills
Vice-Président Directeur et Directeur du Groupe
Groupe IBM Software
Avant-propos de Sogeti
L’un des aspects les plus intéressants de mon métier de PDG de Sogeti est
que je rencontre un grand nombre de dirigeants d’entreprises avec qui j’ai
des discussions passionnantes sur l’évolution du rôle de l’informatique dans
l’environnement économique de plus en plus compétitif qui est le leur. Je suis
toujours étonné de la vitesse à laquelle les organisations doivent s’adapter au
changement. D’habitude l’informatique est l’un des moteurs essentiels du
changement, mais trop souvent elle se révèle également un frein à la liberté
de manœuvre.
Le livre que vous avez sous les yeux est un livre important. Tout d’abord parce
qu’il concerne l’avenir de l’informatique et la façon dont celle-ci sera capable
de soutenir l’agilité économique nécessaire au succès. Dans un monde où la
constante est finalement le changement, un catalyseur de changement doit
devenir la clé de voute des systèmes d’information.
L’architecture orientée services est une philosophie et une approche destinées à augmenter l’agilité dès le départ et, grâce à une réutilisation systématisée, à réduire les efforts de création et de pérennisation des fonctionnalités.
Cependant, ce n’est là qu’une facette de l’histoire. La SOA représente un
véritable état d’esprit qui peut avoir une influence considérable sur la collaboration entre managers et responsables informatiques pour atteindre leur
objectif commun d’une plus grande agilité économique. La SOA ouvre la voie
d’une automatisation des fonctions commerciales ou institutionnelles détachée des contraintes infrastructurelles et alignée sur les besoins opérationnels. En d’autres termes, l’agilité économique ne peut être atteinte que lorsque l’accent est déplacé du fonctionnel, de la tuyauterie administrative, vers
les business processes transfonctionnels qui s’affranchissent des limites purement liées à l’organisation, voire des limites mêmes de l’entreprise. Dans un
monde où la valeur qu’ajoute une organisation devient de plus en plus transparente, il semble plus que logique de se concentrer sur les processes par
lesquels cette valeur est ajoutée.
C’est pourquoi je suis convaincu que la SOA n’est pas seulement un moyen
pratique de déployer l’informatique, elle induit également une approche stratégique de redéfinition des organisations selon une approche process, et tient
la promesse d’une agilité économique soutenue de façon inhérente par des
systèmes d’information qui ne sont plus seulement des facilitateurs mais des
inspirateurs de changement.
11
Ceci dit, je suis plus que conscient des risques que comporte une telle affirmation. Quand des responsables informatiques commencent à parler de restructuration de l’entreprise pour lui donner une plus grande agilité économique, la plupart des managers ne peuvent s’empêcher d’être légèrement
sceptiques. Et dans un monde où se succèdent les booms et les éclatements
de bulle technologiques, difficile de leur en vouloir.
C’est ici qu’intervient ce livre. Bien que les objectifs ultimes de la SOA soient
assez ambitieux, il est de la plus grande importance de suivre un chemin
réaliste, pas à pas, pour atteindre ces objectifs. En outre, chaque pas effectué
doit apporter un bénéfice immédiat en termes de business. Voilà précisément
ce que propose l’approche décrite dans SOA for Profit : une approche pragmatique et concrète de la SOA où les concepts techniques sont éclairés par
une approche business et où l’agilité économique est créée par de nouvelles
formes de collaboration entre le management et l’informatique. Ce livre
apporte suffisamment d’inspiration pour justifier un investissement dans ce
nouveau type d’architecture. Il offre par ailleurs tous les conseils nécessaires
pour s’assurer que la valeur économique attendue est bien là à l’arrivée. En
ce sens, la destination du chemin qu’il aide à parcourir est parfaitement claire,
c’est la route à suivre qui l’est en général moins. La promesse de la SOA, c’est
l’agilité économique et une amélioration considérable de la relation entre
management et informatique. Cependant, il y a de nombreux périls à surmonter tout au long du chemin. Pour commencer ce voyage, une bonne dose de
pragmatisme est tout aussi importante qu’un bon sens de l’orientation. Je suis
convaincu que l’apport principal de ce livre consiste en le développement
chez ses lecteurs d’un « leadership SOA » qui est d’une importance considérable si l’on veut tirer profit de l’architecture orientée services.
Luc François Salvador
Président Directeur Général
Sogeti
12
Préface
IBM et Sogeti sont deux entreprises au parcours irréprochable. L’architecture
orientée services constitue l’un des domaines où leur collaboration se montre
la plus étroite. L’idée d’écrire un ouvrage réunissant leur vision sur ce sujet a
vu le jour en été 2006. Voici le résultat moins d’un an après. Il s’agit d’une
grande réussite, étant donné qu’une équipe internationale issue de deux
sociétés distinctes a dû s’atteler à la tâche, que la plupart des collaborateurs
se connaissaient très peu, et qu’ils parlaient six langues différentes. C’est avec
une immense fierté que nous présentons aujourd’hui SOA for Profit.
Cet ouvrage est un guide destiné aux directeurs et architectes responsables
de la mise en œuvre de la SOA ou très impliqués dans celle-ci au sein de leurs
entreprises. Nous avons décidé de créer cet ouvrage à leur intention, ce qui
signifie que les aspects techniques et technologiques n’ont pas été abordés.
Bien qu’ils soient extrêmement intéressants en soi, leur importance n’est pas
primordiale pour la mise en œuvre de la SOA dans une entreprise. Nous avons
mis l’accent sur les facteurs essentiels qui doivent être abordés : la gouvernance, l’architecture et le développement d’une vision d’ensemble de la
SOA.
Un grand nombre de personnes a participé à l’élaboration de cet ouvrage. Tout
d’abord, les auteurs d’IBM qui ont rédigé les différents chapitres : Norbert
Bieberstein et Gerard Smit ; et les auteurs de Sogeti : Martin van den Berg,
Per Björkegren, Tim Koomen, Craig Mayer, Erik van Ommeren, Bruno Rizzi
et Michiel Vroon.
Différents collaborateurs ont également apporté leur contribution en proposant des meilleures pratiques et toute autre information pertinente. Nous
tenons à exprimer notre plus profonde gratitude à ce sujet envers Manuel De
Juan, Jean-Marc Gaultier, Lon Holden, Philippe Ravix, Gonzalo Rodríguez et
Guillaume Schott.
Nous tenons également à remercier Piet Jan Baarda, Jan Hoogervorst, Ruud
Steeghs, et Marlies van Steenbergen pour leur relecture du manuscrit.
Nous remercions tout particulièrement René Speelman pour sa direction des
ateliers qui ont largement contribué à accélérer la rédaction et la publication
de cet ouvrage.
13
C’est avec le plus grand bonheur que nous l’avons rédigé et nous espérons
que sa lecture vous procurera le même plaisir. Nous vous souhaitons beaucoup de succès dans l’application des connaissances qu’il regroupe lors de la
mise en œuvre de l’approche SOA dans votre entreprise.
N’hésitez pas à nous faire part de vos expériences par e-mail : [email protected].
Mars 2007
Martin van den Berg
Norbert Bieberstein
Erik van Ommeren
14
Table des matières
1 Début du voyage
1.1 Objectif
1.2 Public visé
1.3 Structure
19
20
20
21
2 J’en veux pour mon argent
2.1 Introduction
2.2 Pourquoi la SOA ?
2.3 Pourquoi les entreprises choisissent-elles la SOA ?
2.4 En quoi puis-je être intéressé ?
2.5 Dans quels cas la SOA n’est-elle pas recommandée pour moi ?
2.6 Synthèse
23
23
24
25
32
41
41
3 L’essence de la SOA en sept concepts de base
3.1 Introduction
3.2 Perception de la SOA
3.3 C’est le bon moment
3.4 Les sept concepts de base de la SOA
3.5 Synthèse
43
43
43
44
45
59
4 Gouvernance ou chaos
4.1 Introduction
4.2 Pourquoi la gouvernance est-elle essentielle ?
4.3 Qu’est-ce que la gouvernance SOA ?
4.4 La gestion des portefeuilles de services
4.5 Gestion de cycle de vie des services
4.6 Registre des services
4.7 Architecture d’entreprise
4.8 Comment déployer la gouvernance SOA
4.9 Comment démarrer dans la politique de gouvernance SOA
4.10 Synthèse
61
61
61
66
68
71
73
74
84
92
95
5 Repenser votre activité
97
5.1 Introduction
97
5.2 Quel est votre business model ?
98
5.3 D’une entreprise orientée fonctions à une entreprise orientée services 99
5.4 Éléments d’un business model dynamique
101
5.5 Comment identifiée les éléments de votre business model dynamique 105
5.6 De la structure en silos au partage des ressources
112
5.7 Comment définir des priorités ?
114
5.8 Comment les modèles industriels vous aideront-ils ?
121
5.9 Synthèse
122
15
6 Une entreprise orientée services
6.1 Introduction
6.2 Un exemple
6.3 Une configuration dispersée mais bien cadrée
6.4 Le bus de services humains
6.5 L’importance du Web 2.0 pour une entreprise orientée services
6.6 Synthèse
123
123
123
125
126
131
133
7 Des collaborateurs orientés services
7.1 Introduction
7.2 Rôles SOA
7.3 L’impact sur les collaborateurs
7.4 Synthèse
135
135
135
144
148
8 Comment se préparer à la SOA ?
8.1 Introduction
8.2 Modèle de maturité SOA
8.3 Vingt secteurs clés de la maturité SOA
8.4 Tout ne se fera pas nécessairement en un jour
8.5 Utilisation du modèle de maturité SOA
8.6 Action ciblée
8.7 Synthèse
149
149
150
152
157
163
168
169
9 Comment démarrer la SOA ?
9.1 Introduction
9.2 Votre feuille de route SOA
9.3 Les points d’entrée
9.4 Synthèse
171
171
171
179
194
10 Comment arriver à bon port
10.1 Présentation
195
195
10.2 Comment définir une stratégie de tests SOA ?
10.3 Les différentes étapes de l’approche BDTM
10.4 Avantages de l’approche BDTM
10.5 L’environnement de test SOA
10.6 Adaptation pendant les tests SOA
10.7 Synthèse
11 Les dix meilleures choses à dire pour se faire renvoyer
11.1 « N’en parlons pas au métier »
11.2 « Faites-moi confiance : la SOA, ça coule de source »
11.3 « L’orientation processus est inutile »
11.4 « Construisons une tour de Babel »
11.5 « Demandons à notre nouvel architecte d’entreprise »
11.6 « Changeons les standards »
11.7 « Lançons-nous avec la SOA à l’assaut des cibles mobiles »
16
198
199
208
209
210
212
215
215
218
219
220
221
222
223
11.8 « Que mille services éclosent »
11.9 « Orientons-nous services sans architecture »
11.10 « Migrons tout vers la SOA »
224
225
226
12 Le voyage continue
12.1 Destinations futures
12.2 À condition de…
12.3 Passez à l’action
229
230
233
234
13 Annexe : Modèle de maturité SOA
13.1 Présentation
13.2 Engagement et motivation
13.3 Relations avec les projets
13.4 Rôles et responsabilités
13.5 Développement de l’architecture
13.6 Utilisation de l’architecture
13.7 Outils architecturaux (méthodologie et logiciels)
13.8 Gestion de qualité
13.9 Gestion de portefeuille de services
13.10 Vision de l’architecture
13.11 Alignement des systèmes d’information sur le métier
13.12 Budgétisation et planification
13.13 Technologie et standards
13.14 Subdivision et réutilisation
13.15 Mise en œuvre de processus métiers dans le système
d’information
13.16 Souplesse du système d’information (infrastructure et applications)
13.17 Sécurité
13.18 Compétence SOA des informaticiens
13.19 Compétence SOA des professionnels métiers
13.20 Connaissance et état d’esprit SOA des informaticiens
13.21 Connaissance et état d’esprit SOA des professionnels métiers
13.22 En guise de conclusion
235
235
237
238
240
241
242
243
244
246
247
248
250
251
252
Références
Index
À propos d’IBM
À propos de Sogeti
À propos des auteurs
263
267
271
273
274
253
254
256
257
258
259
260
261
17
1
Début du voyage
Tout voyage, même le plus long, débute par un premier pas.
Mais en quoi doit consister ce premier pas si l’on souhaite résoudre les principaux problèmes auxquels sont confrontées aujourd’hui les entreprises qui
ont recours à l’informatique ? Comment empêcher que des coûts de maintenance de plus en plus élevés paralysent une entreprise ? Comment parvenir
à une situation dans laquelle vos délais de mise sur le marché sont suffisamment courts pour avoir une chance de survivre dans le monde de l’Internet
aujourd’hui ? Comment éviter les obstacles actuels que représentent les silos,
la programmation spaghetti et les rigidités informatiques ?
L’architecture orientée services (SOA) constitue une nouvelle étape vers la maturité informatique en tant que discipline professionnelle, et vers la façon dont
l’entreprise peut utiliser l’informatique. Elle représente un style architectural
dans lequel les systèmes, divisés en concepts de base et associés les uns aux
autres, sont les garants d’une informatique très souple et maîtrisable. Le concept
fondamental est que l’informatique est constituée de services, de composants
élémentaires qui restent relativement stables indépendamment des changements au sein de l’entreprise. Ces services sont ensuite utilisés afin de développer rapidement de nouveaux produits et services. La SOA permet également
d’éviter les impasses liées à l’augmentation constante des coûts de maintenance
et de gestion. Grâce à la SOA et à la réutilisation inhérente de services, la maintenance des systèmes d’information est facilitée et son coût réduit. Mais, surtout,
l’architecture orientée services n’est pas une simple évolution du secteur informatique ; elle induit également un impact à long terme pour l’entreprise qui
l’adopte. L’aspect organisationnel revêt effectivement une importance décisive.
La nécessité de garantir une cohérence, lorsque différents changements
interviennent, ne facilite pas la mise en œuvre de la SOA. Des mutations
devront être opérées sur votre système d’information ainsi que dans les relations que votre entreprise entretient avec ce même système. D’emblée, il vous
faudra fixer vos objectifs business et déterminer dans quelle mesure il est
réaliste ou non d’espérer atteindre ces objectifs grâce à la SOA. Quoi qu’il en
soit, la SOA n’est pas un objectif en soi, il ne s’agit pas d’une technologie toute
faite, ni d’une solution miracle. La SOA est une architecture dotée de toutes
les propriétés qui s’y rattachent : sa mise en œuvre progressive demande
discipline et patience.
19
SOA for Profit
Si vous décidez de mettre en œuvre une SOA, vous ne pourrez pas tout traiter
de front. Il vous faudra définir des priorités, faire des choix. Dès lors, vous
pourrez planifier la première étape. Celle-ci se compose principalement de
projets commerciaux à valeur ajoutée directe ainsi que de projets qui se prêtent à une préparation des différents aspects de votre entreprise en prévision
de l’application de la SOA.
L’architecture orientée services est là pour durer. Tout comme il serait illogique de se passer des mathématiques, il serait imprudent de faire l’économie
des notions que recouvre la SOA. En ce sens, la SOA se distingue, par sa
nature, des autres concepts à la mode : ce n’est pas une tendance, mais un
accélérateur de croissance. C’est ce qui en rend l’approche séduisante. Alors,
prêts pour la croissance ?
1.1 Objectif
SOA for Profit est un guide qui vous permettra d’organiser votre démarche
vers la SOA et d’atteindre vos objectifs avec succès. Des axes d’approche, des
modèles et des conseils vous sont donnés afin que vous puissiez formuler une
vision SOA, savoir où vous en êtes et définir votre itinéraire de migration vers
la SOA.
Ce manuel vous permet :
•
d’évaluer la valeur ajoutée de la SOA pour votre entreprise.
•
de comprendre les concepts que recouvre la SOA.
•
d’analyser les conséquences de la mise en œuvre de la SOA.
•
d’identifier les actions nécessaires pour la mise en œuvre de la SOA au
sein de votre entreprise.
1.2 Public visé
Cet ouvrage a été spécialement rédigé pour les personnes chargées de la mise
en œuvre de la SOA au sein de l’entreprise, notamment les directeurs des
systèmes d’information (DSI), responsables informatiques, directeurs commerciaux, directeurs de l’information, gestionnaires de processus, gestionnaires du changement, directeurs de projets et architectes d’entreprise, qui peuvent tirer un très large profit de ce document.
20
1 Debut du voyage
Il est également utile aux personnes régulièrement impliquées dans les projets SOA au sein de l’entreprise telles que les directeurs de produit, architectes métiers, analystes d’entreprise, ingénieurs en logiciels et testeurs.
1.3 Structure
L’architecture orientée services est présentée de façon de plus en plus
concrète et pratique au fil de l’ouvrage. L’approche adoptée part du concept
et de la vision pour aller vers des projets concrets tout en signalant les pièges
à éviter.
Dans le chapitre 2, l’ouvrage aborde les bonnes raisons de choisir une approche SOA. Pourquoi en parlons-nous ; pourquoi est-elle si intéressante ? Ce
chapitre illustre l’essence même de ce manuel. Il présente des exemples d’entreprises qui ont tiré profit de la mise en œuvre de la SOA.
Le chapitre 3 traite de l’essence de la SOA sous la forme de sept concepts de
base, en abordant la condition préalable indispensable à une application
réussie d’une approche SOA : la gouvernance. Sans une quelconque forme de
gouvernance, la mise en œuvre de la SOA conduira irrémédiablement au
chaos. Le chapitre 4 montre que la gouvernance et l’architecture d’entreprise
sont indispensables. À cet égard, des conseils pour la mise en place de ces
compétences au sein de votre entreprise vous seront donnés.
Autre condition préalable à la mise en œuvre de la SOA : débuter par le métier.
Une fois que les services ont été conçus, le métier tient lieu de point de départ.
Cela n’est possible qu’au prix d’une certaine forme d’abstraction, également
appelée « modélisation métier ». Pour cette modélisation, il est possible d’utiliser des modèles industriels existants. Ces modèles font l’objet du Chapitre 5.
Penser en termes de services ne doit pas se limiter aux systèmes informatiques. Une entreprise elle-même peut être définie en termes de services, ce
qui permet d’introduire la dimension d’« entreprise orientée services ». Le
chapitre 6 aborde cette perspective supplémentaire pour la SOA.
Le chapitre 7 traite de l’incidence de la SOA sur le personnel au sein de l’entreprise. N’oublions pas que la SOA implique une façon de travailler différente lorsque les changements concernant l’activité et l’informatique ont été
mis en œuvre.
21
SOA for Profit
Les chapitres 3 à 7 couvrent en détail les conséquences et conditions préalables relatives à la mise en œuvre de la SOA. L’impact de la SOA est fort et toute
mise en œuvre implique des conséquences importantes. Le chapitre 8 regroupe
ces conséquences et les inscrit dans la perspective d’un modèle de maturité
SOA. Ce modèle vous permet de déterminer le degré de maturité de votre
entreprise dans le domaine de la SOA, ainsi que les mesures d’amélioration
que vous pouvez mettre en œuvre afin d’atteindre le niveau recherché.
La mise en œuvre de la SOA s’inscrit pour l’essentiel dans des projets générant une forte valeur ajoutée. Il s’agit de projets dans lesquels l’entreprise
investit en lançant un nouveau produit sur le marché, par exemple, ou en
améliorant ses procédés. Le chapitre 9 traite de l’identification des projets
cibles pour l’application de la SOA. Les soi-disant « points d’entrée » servent
de support à ce procédé.
Avec la SOA, l’entreprise se voit proposer un large éventail de composants
(services) aussi autonomes que possible et utilisables en différents lieux. Afin
de réussir son voyage vers la SOA, il est indispensable de tester convenablement les services et processus métiers dans lesquels ces services seront utilisés. Cela fait l’objet du chapitre 10.
La mise en œuvre d’une approche SOA entraîne toute une série de conséquences. Des entreprises qui étaient pionnières dans ce domaine ont été
confrontées à de multiples obstacles que vous pouvez éviter plus efficacement. Le chapitre 11 présente une synthèse de ces principaux pièges.
Enfin, le chapitre 12 présente un résumé et spécule sur l’avenir de la SOA.
Des informations plus détaillées concernant le modèle de maturité SOA sont
fournies en l’Annexe.
SOA for Profit n’est pas un manuel technique. Le défi inhérent à la mise en
œuvre d’une SOA consiste dans une plus large mesure à préparer l’entreprise
à accroître ses chances de succès et à tenir effectivement les promesses
qu’apporte la SOA, à savoir plus de souplesse et des coûts réduits.
Cet ouvrage contient différents exemples tirés de cas réels. Ils sont présentés
dans des encadrés afin d’être facilement identifiables.
22
2
J’en veux pour mon argent
2.1 Introduction
L’informatique au sein de votre entreprise constitue-t-elle toujours le point
critique lorsque votre métier est prêt à innover ? Essayez-vous depuis des
années d’intégrer des processus et des systèmes à la suite d’une fusion ou d’une
acquisition ? Vous arrive-t-il de perdre des marchés parce que vous présentez
vos nouveaux produits trop tard ? L’informatique et le métier éprouvent-ils de
grandes difficultés à se comprendre ? Les frais de gestion et de maintenance
informatiques connaissent-ils une forte croissance au sein votre entreprise ?
Si vous vous reconnaissez dans l’une de ces questions, la suite de cet ouvrage
vous concerne. La SOA vous permettra de prendre ces problèmes à bras le
corps. Elle constitue un moyen d’organiser le département informatique et le
département commercial de façon à donner davantage de souplesse et d’efficacité à votre entreprise.
En 2000, une importante société de services financiers a observé que son ratio coût/
revenu, considéré par les banques comme un facteur d’efficacité, était de 70,8 %. Cela
faisait d’elle l’une des moins performantes du secteur. Le niveau relativement élevé des
coûts découlait d’un fonctionnement et d’une informatique fragmentés et par conséquent inefficaces, freinant la volonté de l’entreprise de devenir un opérateur financier
de classe mondiale. Un changement radical s’imposait. Il fallait réduire les coûts et les
risques, accroître la productivité mais aussi standardiser et consolider le système d’information afin de parvenir à un fonctionnement et à une informatique encourageant
l’activité au lieu de la freiner. À cet effet, une architecture entièrement fondée sur une
approche SOA a été conçue et mise en œuvre au sein de l’entreprise. Le succès a été
au rendez-vous. En 2006, le ratio coût/revenu était descendu à 62,3 %. En partie grâce
à la SOA, l’entreprise était parvenue à réduire ses coûts, à accroître sa souplesse et à
accélérer le développement commercial, autant de promesses SOA tenues.
Les managers ne manqueront pas de s’interroger : « SOA, c’est bien joli, mais
cela me permettra-t-il de gagner de l’argent ? » Ce chapitre montre comment
la SOA apporte une valeur ajoutée. Vous aurez un aperçu des raisons pour
23
SOA for Profit
lesquelles les entreprises choisissent la SOA et des bénéfices qu’elles en
tirent. En outre, vous pourrez entrevoir ce que la SOA peut apporter à votre
cas précis. Ce chapitre vous montrera comment gagner de l’argent.
2.2 Pourquoi la SOA ?
Le changement constitue le seul facteur constant dans la vie de l’entreprise.
C’est principalement la pression extérieure qui pousse les entreprises à
s’adapter en permanence. Les facteurs de changement sont multiples : législation et règlements, opportunités de marché, possibilités technologiques, respect des critères de conformité, croissance du marché en Extrême-Orient,
potentiel de l’externalisation, pression à la baisse sur les coûts, etc. La vitesse
à laquelle les entreprises sont capables d’anticiper ces facteurs détermine leur
aptitude à la compétitivité. Vitesse et souplesse sont ici les clés du succès.
Il n’est pourtant pas facile d’atteindre le niveau requis de vitesse et de souplesse. En effet, les entreprises mettent en œuvre des procédés et des systèmes si complexes et entrelacés, qu’essayer de les adapter constitue un véritable casse-tête. Prenons, comme premier exemple, un détaillant qui connaît
une grande réussite. Le nombre de ses succursales augmente si rapidement
qu’il devient nécessaire d’étendre le code d’établissement. Pas moins de
40 000 heures sont nécessaires pour conduire l’analyse d’impact et déterminer les systèmes à adapter.
Autre exemple, celui d’un organisme gouvernemental dont la productivité
informatique chute à cause de systèmes informatiques toujours plus complexes. Les possibilités d’adaptation des systèmes sont plutôt limitées, alors qu’il
faut de plus en plus de temps pour l’analyse et les tests préliminaires.
La SOA vous permet d’en finir une fois pour toutes avec ces situations. La bonne
application des principes de la SOA dans la structuration des processus et des
systèmes et la mise en œuvre adéquate d’une technologie fondée sur la SOA
représentent pour l’entreprise une garantie irréfutable de vitesse et de souplesse.
Non seulement la SOA libère les procédés des systèmes, mais elle déconnecte
les systèmes les uns des autres (découplage). Les entreprises disposent généralement d’imposants systèmes, à la fois complexes et monolithiques, qui, outre la
multitude de fonctionnalités qu’ils proposent, contraignent la façon dont le processus métiers doit être exécuté. Lorsqu’il devient nécessaire d’adapter ce processus, le système doit lui aussi être ajusté, ce qui implique un immense travail
24
2 J’en veux pour mon argent
de recherche et de test. Grâce à l’approche SOA, la fonctionnalité peut être divisée en unités plus petites telles que « présenter nouveau client », par exemple.
Ce type d’unités est proposé en tant que service, en tant que tâche automatisée,
à tous les processus métiers dans lesquels le nouveau client est présenté. Lorsqu’un processus métiers doit être adapté, cela se fait de façon beaucoup plus
simple et rapide, puisqu’il n’est plus nécessaire d’intervenir dans la totalité du
système. En outre, un service peut être réutilisé dans différents processus métiers,
ce qui se traduit par des économies substantielles puisqu’on réutilise ce dont on
dispose déjà au lieu d’acheter quelque chose de nouveau. Cela se traduit également par un nombre plus réduit de logiciels à entretenir et à supporter.
On peut avancer à juste titre que la SOA représente une avancée décisive :
elle constitue la nouvelle étape dans le processus de maturation de l’informatique. Aujourd’hui, elle donne à la fonction informatique les moyens appropriés pour communiquer avec l’entreprise dans un langage commun. Après
tout, il est possible de définir les fonctionnalités requises en termes de services. La façon dont ces fonctionnalités sont ensuite fournies par l’informatique
ne revêt pas d’intérêt particulier pour l’entreprise. Le « quoi » est totalement
indépendant du « comment ».
La mise en œuvre de la SOA n’est pas un objectif en soi. La SOA est un moyen
d’accroître la souplesse et la rentabilité d’une entreprise. De ce fait, si ces objectifs liés à l’activité jouent un rôle important au sein de votre entreprise, alors la
SOA mérite d’être prise en considération. À plus long terme, nous espérons que
la SOA deviendra, de fait, le modèle architectural en matière d’organisation commerciale et informatique. Les gros fournisseurs d’applications métiers, tels que
SAP, Microsoft et Oracle, investissent des centaines de millions de dollars afin de
pouvoir proposer leurs applications sous forme de services. En outre, les fournisseurs de logiciels et de matériels tels qu’IBM et HP investissent des fortunes
pour rendre leurs produits compatibles avec la SOA. Si la SOA ne s’impose peutêtre pas à vous actuellement, tôt ou tard, vous y serez confronté. D’où l’importance de lire et d’examiner ce que la SOA peut apporter à votre entreprise.
2.3 Pourquoi les entreprises choisissent-elles la SOA ?
Plusieurs raisons expliquent que les entreprises fassent le choix de la SOA.
Pour certaines, il s’agit d’une conséquence logique de la stratégie métier
qu’elles ont retenue ; pour d’autres, ce n’est pas un choix mais plutôt une
question de survie.
25
SOA for Profit
L’exemple proposé dans l’introduction concerne une société qui a fait le choix
de la SOA pour satisfaire son ambition de devenir un prestataire financier de
classe mondiale. Nous allons maintenant exposer trois cas pratiques qui
expliquent les raisons pour lesquelles les entreprises choisissent la SOA :
1. Considérations stratégiques : l’environnement économique dont fait partie
l’entreprise est sur le point de changer.
2. Question de nécessité : la SOA est la seule alternative de survie.
. Combinaison d’une technologie obsolète et d’évolutions métiers induites
par le secteur économique.
Le premier exemple concerne une entreprise qui voit dans la SOA un choix
stratégique lié à son nouveau rôle dans les activités de virement monétaire
en Europe.
Exemple d’une chambre de compensation automatisée
L’une des chambres de compensation automatisées les plus importantes et évoluées
d’Europe a adopté la SOA comme principe de structuration de son métier et de son
système d’information. Le choix de la SOA est dicté par l’internationalisation croissante du secteur du virement monétaire en Europe et, partant, par le positionnement
de cette entreprise comme prestataire de service intégral dans le traitement des
Chaîne de paiement
Client
Services d’entreprise
Procédé
Procédé
Application
Application
Infrastructure
Figure 2.1 : La chaîne SOA
26
2 J’en veux pour mon argent
opérations de virement et de carte, d’arbitrage, de compensation et de règlement.
Ce choix induit une coopération plus étroite dans la chaîne des processus de l’entreprise et il ouvre la porte à d’éventuelles fusions. Cette société a choisi la SOA pour
des raisons de souplesse de l’activité et de gestion des coûts. Une déconnexion très
stricte des couches informatiques (cf. Figure 2.1), combinée à un lien architectonique
intégré avec les divers processus, constitue une fonctionnalité centrale de la SOA qui
devrait permettre l’interruption ou l’évitement de toutes connexions erratiques et de
tous chevauchements entre processus. Le produit n’est pas cantonné à la société
elle-même : il s’étend également aux groupes de fusions éventuelles, aux clients et
aux autres partenaires de la chaîne. Ainsi, la SOA ne se limite pas au domaine informatique mais débute avec les services que la société propose sur le marché et s’étend
jusqu’aux services assurés par le domaine des infrastructures, pour permettre le
fonctionnement des applications. Le résultat final est un meilleur alignement, plus
dynamique, entre l’activité de l’entreprise et son informatique.
Il existe également des entreprises qui font le choix de la SOA faute d’autres
solutions. Elles doivent appliquer la SOA pour survivre. C’est une question de
« vie ou de mort ». Les processus et systèmes ont atteint un tel niveau de
complexité que l’entreprise menace de s’écrouler. C’est ce que montre ce
deuxième exemple.
Exemple d’une entreprise de télécommunications
Qu’est-ce qui pousse un opérateur de télécommunications bien établi, fort de plus
de 8 millions de clients, à migrer vers la SOA pour tous ses processus liés à son
activité de prépaiement, et ce dans un énorme projet de 12 millions d’euros sur deux
ans ?
Pourquoi une situation aussi complexe ?
Décrivons ici le scénario initial à l’origine de cette décision drastique.
Des développements de qualité insuffisante
S’il existe des traits communs entre les modèles économiques des fournisseurs de
services en téléphonie cellulaire et mobile, ce sont bien la vitesse et l’agressivité des
délais de mise sur le marché de nouvelles offres. Cette situation nécessite des cycles
de vie et de développement très courts qui mettent à rude épreuve le savoir-faire
et l’endurance des équipes de développement. Si vous voulez être le premier à
proposer un nouveau service, vous ne devez rater aucune échéance ni aucun
délai.
27
SOA for Profit
Toutefois, cette nécessité d’aller vite a souvent des conséquences néfastes si elle n’est
pas gérée de manière adéquate. C’était le cas pour cet opérateur de télécommunications. Malgré la présence d’un département Qualité des logiciels, chargé de mettre en
place les procédures de développement et les pratiques professionnelles, les phases
d’analyse et de conception étaient généralement négligées au sein des projets de développement : elles étaient considérées comme des étapes « non productives » par manque
de temps. Chacun s’efforçait ainsi de livrer au plus tôt quelque chose qui fonctionnait,
sans prêter suffisamment attention à la qualité. Il en a résulté plusieurs scénarios :
• Les modules logiciels (formulaires en ligne, tâches en paquets, transactions etc.)
devenaient des domaines obscurs et inextricables que personne n’avait véritablement le temps d’explorer pour s’assurer que les choses avaient été faites et comment. Aucune phase d’analyse et de conception digne de ce nom n’était mise en
place. Chaque nouveau développement ne faisait qu’accroître l’imbroglio.
• Les nouveaux développements de services étaient rarement alignés sur les développements existants. Jamais personne ne consacrait le temps nécessaire à tenter
d’explorer la meilleure façon d’adapter le produit à l’ensemble du portefeuille.
• On souffrait d’un manque d’information sur les modules communs à la disposition
des diverses équipes de développement, car la documentation n’avait pas été
traitée comme une étape critique. Aucune structure ne couvrait les opportunités
de réutilisation.
Dépenses élevées dans la maintenance des environnements de production
Conséquence directe de la qualité insuffisante du développement, les logiciels livrés,
voire les environnements de production, accumulaient les défauts. Dans bien des cas,
ces derniers n’étaient pas simples à supprimer car ils étaient noyés dans des modules
logiciels non structurés, assez chaotiques. Ainsi, les budgets et ressources nécessaires
pour soutenir ces environnements critiques (si proches de l’utilisateur final) augmentaient considérablement d’année en année, compromettant gravement l’exploitation
de l’ensemble de l’entreprise.
Une architecture incapable de s’adapter à l’évolution des marchés
L’opérateur de télécommunications était fortement centré sur son système de gestion
de la relation clients (GRC, CRM en anglais)” en raison d’une décision stratégique
majeure prise plusieurs années auparavant, lorsque les centres d’appels constituaient
le principal point d’entrée de chaque transaction avec les clients : nouvelles demandes de services, changements dans les services existants, modifications des informations clients, etc. L’architecture informatique avait donc été fortement influencée par
cette décision de gestion. La quasi-totalité des développements de processus métiers
étaient hébergés à l’intérieur de leur GRC, et les autres systèmes étaient esclaves du
système maître.
28
2 J’en veux pour mon argent
GRC
Facturation
Commercialisation
Logique métier
Évolution du plan
de tarification
A
Entrepôt de données
Mise en réseau
Figure 2.2 : Évolution du plan de tarification
Dans la Figure 2.2, la logique métier était hébergée dans le système GRC, les changements étaient intégrés dans les bases de données système, puis les autres systèmes
étaient avisés de ces changements.
D’autres améliorations technologiques ont permis à d’autres canaux de devenir au
moins aussi pertinents que les centres d’appels (GRC classique). Ils ont accueilli des
portails interactifs, des services SMS, des systèmes SVI et bien d’autres fonctions.
Ils devaient assurer une souplesse à l’utilisateur, offrant au client plusieurs choix
possibles pour effectuer une même action. Qu’est alors devenue la logique
métier ?
Sur la Figure 2.3, la logique métier consistant en une évolution du plan de tarification
était si intégrée dans la mise en œuvre du GRC qu’il devenait impossible pour d’autres
canaux nouveaux de la réutiliser. En conséquence, chaque canal construisait sa
­propre solution pour répondre à un même procédé.
On imagine facilement les complications qu’a pu engendrer ce type d’architecture.
Dans ce processus, dès lors qu’un changement était nécessaire, il fallait le déployer
dans quatre environnements différents ! Il existait également des équipes de maintenance différentes, attachées à ces systèmes, de sorte que les patchs de résolution des
défauts étaient également divergents. En quelques mois, ce processus qui était censé
assurer la même fonctionnalité, quel que soit le canal utilisé, évoluait vers la production de fonctionnalités diverses qui réglaient les mêmes problèmes de façon différente. L’architecture de l’opérateur de télécommunications manquait de la souplesse
d’adaptation rapide qu’exigeait le marché. Le choix de la SOA s’imposait comme une
évidence.
29
SOA for Profit
IVR
Logique métier
Évolution du plan
de tarification
A’’
GRC
Facturation
Commercialisation
Logique métier
Évolution du plan
de tarification
A
Entrepôt de données
Mise en réseau
WEB
SMS
Logique métier
Évolution du plan
de tarification
A’
Logique métier
Évolution du plan
de tarification
A’’’
Figure 2.3 : Conséquences de l’évolution du plan de tarification
Le troisième et dernier exemple est celui d’une société qui a choisi la SOA
en raison de l’obsolescence de sa technologie et de l’évolution de la
demande.
Exemple des hôtels Starwood
En 2001, Starwood Hotels a pris conscience que son avenir passait par une architecture orientée services [CIO Insight 2006]. Cette chaîne d’hôtels internationale, qui regroupe des enseignes telles que les hôtels St. Regis, Sheraton, Westin’s et les W Hotels, a constaté que son ancien système, peu pratique et onéreux,
limitait la capacité de l’entreprise à s’adapter rapidement aux canaux de distribution en pleine expansion tels que l’Internet. Il était trop difficile d’ajouter des
capacités supplémentaires au système GRC ou encore de lancer des recherches
de propriétés ; en bref, ce dont un environnement informatique moderne a
besoin.
30
2 J’en veux pour mon argent
Les systèmes de Starwood avaient également du mal à traiter le trafic de plus en plus
conséquent sur ses sites Internet, ce que les professionnels de l’hôtellerie appellent
le ratio look-to-book. Au début d’Internet, le ratio look-to-book était de 50 pour 1. Il est
aujourd’hui de 300 pour 1. Starwood avait donc besoin d’un environnement informatique capable de traiter toutes ces demandes. Conserver le système patrimonial
aurait nécessité plusieurs millions de dollars d’investissement dans les remises à
niveau et le support technique. Cela supposait des investissements considérables et
Starwood ne voulait pas être pénalisé.
Starwood s’est donc lancé dans le long processus consistant à faire migrer ces
systèmes vers un cadre SOA ouvert. C’était le meilleur moyen de faire correspondre la technologie à ses différentes enseignes. Au lieu que chaque chaîne d’hôtels
de Starwood construise ses propres applications, la SOA a permis aux enseignes
de partager les mêmes programmes et les mêmes caractéristiques, personnalisables en fonction des besoins et spécificités de chaque hôtel. La fonction « recherche » de Sheraton peut, par exemple, fournir des informations d’une manière différente de celle de W Hotels, même s’il s’agit du même programme. Pour Starwood,
l’avantage consiste à utiliser les mêmes outils activables par différentes applications et interfaces.
Parce qu’elle assouplit les relations de dépendances, les services pouvant être activés
au travers de différents systèmes et environnements d’exploitation, la SOA offre également à la société la flexibilité nécessaire pour créer de nouveaux outils. Starwood a
notamment mis en place une application qui permet de suivre les demandes et les
réclamations des clients. L’entreprise a également créé un programme qui stocke et
suit les préférences des clients réguliers.
Mais cela ne s’est pas fait du jour au lendemain. Après cinq ans, l’entreprise est
enfin prête à démanteler officiellement son ancien système, une mesure qui lui
permettra d’économiser jusqu’à 20 millions de dollars par an en frais de maintenance.
Ces trois exemples montrent qu’une entreprise peut choisir la SOA pour de
multiples raisons : considérations stratégiques, comme dans le premier
exemple où l’environnement économique dont fait partie l’entreprise est
sur le point de changer ; nécessité, comme dans le deuxième exemple ; ou
encore limites atteintes par l’ancien système, comme dans le troisième
exemple.
31
SOA for Profit
2.4 En quoi puis-je être intéressé ?
La question des bénéfices tirés de la SOA dépend entièrement de votre situation et notamment des problèmes et défis auxquels est confrontée votre
entreprise. Le moyen de s’assurer que la SOA est bien adaptée à votre situation consiste à formuler une vision d’entreprise pour la SOA. Cette vision
d’entreprise permet de se forger une idée claire des avantages et conséquences induits par le choix de la SOA. La vision d’entreprise permet de déterminer si la SOA doit ou non être mise en œuvre et, si oui, par où il convient de
commencer. Afin de présenter brièvement les avantages garantis par la SOA,
nous nous servirons d’une étude réalisée par IBM sur 35 mises en œuvre de
la SOA dans 5 secteurs industriels différents [IBM Global Business Services
2006b]. Cette étude a montré qu’une plus grande souplesse de l’entreprise
constitue le principal avantage de la mise en œuvre de la SOA, la réduction
des coûts venant juste derrière. Le Tableau 2.1 présente, par ordre d’importance, les avantages de la mise en œuvre de la SOA.
Souplesse accrue
•
•
•
•
Capacité au changement supérieure
Réutilisation accrue des actifs
Réduction du temps d’intégration des systèmes
Réduction du temps de mise sur le marché
Réduction des coûts
•
•
Réduction du coût d’intégration des systèmes
Réduction du coût de développement et de
maintenance des systèmes
Réduction des coûts de fonctionnement
informatiques et commerciaux
•
Réduction des risques
•
•
•
Réduction du coût d’intégration des systèmes
Réduction du coût de développement et de
maintenance des systèmes
Réduction des coûts de fonctionnement
informatiques et commerciaux
Augmentation du chiffre
d’affaires
•
•
•
Création de nouvelles sources de revenus
Croissance des sources de revenus actuelles
Maintien des sources de revenus actuelles
Développement de nouveaux
produits
•
Création de nouveaux services par l’utilisation des
systèmes actuels et/ou nouveaux
Création et livraison accélérée de nouveaux
produits
•
Conformité
•
•
Transparence accrue
Exactitude et surveillance accrues
Tableau 2.1 : Avantages constatés des projets de SOA
32
2 J’en veux pour mon argent
De plus, l’étude IBM montre que plusieurs raisons justifiaient la mise en œuvre
de la SOA. Ces raisons, présentées dans le Tableau 2.2, semblent être liées en
partie à la frustration et en partie aux opportunités de marché, comme l’indique la conclusion des trois exemples abordés dans la section précédente.
Nécessité de
changement de
technologie
•
•
•
Environnements patrimoniaux vieillissants/inadaptés
Capacité insuffisante, fiabilité réduite
Systèmes rigides, peu aptes aux changements
Possibilité de
collaboration
•
Nécessité d’échanger des informations et des services
avec les partenaires, fournisseurs, distributeurs et clients
Pression de la
concurrence
•
Anticipation plus rapide de la concurrence, qui dispose
de solutions plus souples
Livraison plus rapide de produits et services
Amélioration des services clients (services clients/
satisfaction client)
•
•
Législation
•
Conformité/mandats juridiques provenant du
gouvernement et/ou de l’entreprise elle-même
Exigences fournisseur/
distributeur
•
•
Demande d’une meilleure connectivité
Moindre responsabilité vis-à-vis des solutions point à point
Nouveaux marchés
•
Utilisation des services actuels et nouveaux pour
l’ouverture de nouveaux canaux
Tableau 2.2 : Motivations des projets SOA
Ainsi, dans la pratique quotidienne, il existe différents avantages et raisons
de choisir la SOA ; ce sont des éléments qui constituent en partie la vision
d’entreprise (cf. Figure 2.4).
Raisons
Avantages
Vision
d’entreprise
Mise en œuvre
Définition
Conséquences
Figure 2.4 : Éléments de la vision d’entreprise SOA
33
SOA for Profit
La vision d’entreprise se compose de cinq éléments : raisons, avantages, définition, conséquences et mise en œuvre. Nous allons maintenant les aborder
en détail.
Raisons
La décision d’entreprendre une démarche SOA ne tombe pas du
ciel. Elle doit être motivée. La motivation peut avoir différentes
origines, tant à l’intérieur qu’à l’extérieur de l’entreprise. Parmi les facteurs
internes, citons par exemple un paysage applicatif totalement bouché et incapable d’accepter la moindre modification supplémentaire, ou une entreprise
qui souhaite passer du tout produit au tout processus. Parmi les facteurs
externes, citons par exemple un fournisseur de progiciels standard qui a intégré des services dans la dernière version de ses outils, ou un partenaire qui
fournit des services Internet au lieu d’échanger des données au moyen de
messages EDI. La raison est souvent liée à un dysfonctionnement ou à un
besoin urgent. Le dysfonctionnement est interne à l’entreprise et doit être
résolu ; il faut faire en sorte qu’il ne puisse se reproduire. Un besoin urgent
est presque toujours déclenché par un élément extérieur et doit généralement
être résolu sans remise en question du fonctionnement de l’entreprise (business case).
Avantages
L’étape suivante dans la définition de la vision d’entreprise
consiste à déterminer les avantages de la SOA. Il serait tentant
d’accepter la première liste venue. Essayez de résister à la tentation. Il est
important de définir les avantages pour l’entreprise de façon aussi spécifique
que possible. Cela signifie qu’il doit exister un lien entre les objectifs de l’entreprise et les possibilités offertes par la SOA. Nous avons développé deux
questionnaires afin de vous permettre d’identifier ce lien.
Vous êtes manager, alors ceci vous intéresse !
Imaginez que vous êtes manager et que vous recevez la visite d’un chef de service
informatique qui commence à vous vanter les mérites de la SOA. Que pouvez-vous
faire en tant que manager ?
Réponse : posez des questions ! Prenez le taureau par les cornes et interrogez le chef
du service informatique.
Questions permettant de vous forger une opinion :
• Comment l’informatique peut-elle contribuer à nos objectifs commerciaux ?
34
2 J’en veux pour mon argent
•
•
•
•
En quoi la SOA pourrait-elle contribuer à notre activité ?
La SOA pourrait-elle également être un facilitateur pour notre entreprise ?
Quels sont les secteurs les plus susceptibles de profiter de la SOA ?
Quels sont les risques et les conséquences liés à la mise en place de la SOA ?
Questions spécifiques que le manager doit poser au responsable informatique :
• En quoi l’informatique peut-elle contribuer à la réalisation de mes objectifs commerciaux ?
• Quels services l’informatique peut-elle m’offrir (en tant que métier) étant donné
que notre entreprise propose elle-même des services à ses clients sur le marché ?
• Veuillez expliquer en 5 minutes ce que la SOA signifierait pour notre entreprise et
pour moi en particulier ?
• La SOA semble laborieuse, quelle importance présente-t-elle pour moi ?
• Veuillez me fournir des scénarios montrant comment l’informatique peut me permettre de réduire notre temps de mise sur le marché pour les nouveaux produits ?
• Veuillez me fournir des scénarios montrant comment l’informatique peut m’aider
à réduire les coûts à court et à long terme ?
• Veuillez me fournir des scénarios montrant comment l’informatique peut m’aider
à améliorer l’agilité et la souplesse de notre entreprise ?
• La SOA représente-t-elle simplement une tendance du secteur informatique ou
constitue-t-elle quelque chose de durable et pourquoi ?
• Que dois-je faire pour mettre en œuvre la SOA dans notre entreprise ? Quel délai
et quel coût cette mise en œuvre implique-t-elle ?
• Sommes-nous prêts pour la SOA ? Quand serons-nous prêts ?
• La SOA est-elle adaptée à notre culture ?
• Quels sont les pré-requis pour une mise en œuvre réussie de la SOA dans notre
entreprise ?
• Quels sont les risques liés à la mise en œuvre ?
• Existe-t-il des gains immédiats ?
• Qu’en est-il chez nos concurrents ? Mettent-ils en œuvre la SOA ? Pourquoi ? Quelles sont leurs expériences ?
• Quels sont les avantages pour nos clients et pour moi ?
• Que se passera-t-il si nous décidons de ne pas investir ?
Les réponses à ces questions devraient tirer la sonnette d’alarme au niveau du service
informatique et les amener à penser avec vous au lieu de voir la SOA comme un
objectif en soi.
35
SOA for Profit
Vous êtes chef de service informatique, alors ceci vous intéresse !
Imaginez que vous êtes chef de service informatique et que vous voulez susciter l’intérêt du manager pour la SOA. Que devriez-vous faire ? Dès à présent, vous devez
comprendre que vous ne cherchez pas à vendre mais à évaluer les secteurs où la SOA
apporte une valeur ajoutée à l’entreprise. Là encore, vous devez poser des questions
afin d’évaluer :
• En quoi la SOA peut également être un facilitateur dans votre entreprise
• Les arguments en faveur de la SOA
• Le point de départ
• Le moment pour commencer
• Les risques et les conséquences
Questions que le département informatique doit poser au manager:
• Quels sont nos objectifs commerciaux à court et à long terme ?
• Quelles sont notre mission et notre vision à court terme ?
• Comment nous comportons-nous face à nos concurrents ? Dans quel domaine
sommes-nous supérieurs ? Dans quels domaines sommes-nous moins performants ?
• Quelles sont les forces et les faiblesses de notre organisation ?
• Quelles sont les opportunités et les menaces pour notre entreprise ?
• Existe-t-il des plans d’amélioration des processus métiers ? Dans quels domaines ?
Quels sont les objectifs ?
• Existe-t-il des plans de fusion et d’acquisition ?
• Existe-t-il des plans pour améliorer la gestion de la chaîne logistique ? Quels sont
les objectifs ?
• Existe-t-il des plans de réduction des coûts ? Dans quels domaines ? Quels sont les
objectifs ?
• Existe-t-il des plans pour la mise en place de nouveaux produits ou services, pour
pénétrer de nouveaux marchés ?
• Existe-t-il des initiatives de conformité au sein de notre entreprise ? Quels sont les
objectifs ?
• La synergie est-elle à l’ordre du jour du Conseil d’administration ? Si oui, dans
quels domaines pensez-vous que nous puissions réussir cette synergie ?
• Quel est votre degré de satisfaction vis-à-vis de l’informatique ? Dans quels domaines êtes-vous totalement mécontent ? Dans quels domaines êtes-vous totalement
satisfait ?
• Pensez-vous que l’informatique représente un frein au changement au sein de
notre entreprise ? Si oui, dans quelle mesure ? Veuillez apporter des exemples
concrets.
36
2 J’en veux pour mon argent
•
•
•
•
•
•
•
•
•
•
Que pensez-vous du fait de définir des exigences vis-à-vis de l’informatique en
termes de services et de niveaux de services ?
Pensez-vous que le concept de centres de services communs soit adapté à notre
entreprise ? Pourquoi ?
Comme la plupart des entreprises, nous avons tendance à réinventer la roue.
Quelles possibilités voyez-vous pour la réutilisation des informations, processus,
ou autres ?
Qu’attendez-vous de l’informatique en général ?
Essayez de décrire votre scénario idéal sur la façon dont le management et le
département informatique devraient collaborer.
Quelle est votre pire expérience en matière informatique ?
Quelle est votre meilleure expérience en matière informatique ?
Quelle est votre exigence numéro un en matière informatique ?
Avez-vous déjà entendu parler de la SOA ? Si oui, qu’en pensez-vous ? Y voyez-vous
des avantages pour notre entreprise ?
Dans les prochaines années, quelle sera la capacité la plus importante pour notre
entreprise ? Pourquoi ?
Déterminer les avantages de la SOA ne doit pas être considéré comme un
processus rédactionnel dans lequel un architecte ou un consultant se présente avec un document passionnant et s’installe derrière son bureau, mais
plutôt comme un processus de prise de conscience mettant en œuvre des
ateliers afin d’associer les objectifs commerciaux aux possibilités de la SOA.
Ce processus peut être conçu comme un dialogue stratégique entre le département commercial et le département informatique. Un dialogue stratégique
est un processus continu dans lequel les objectifs sont élaborés sous forme
de propositions de projets concrets grâce à des business cases. Les objectifs
font l’objet d’un dialogue entre le management et le département informatique. La partie livrable d’un dialogue stratégique vis-à-vis de la SOA est une
liste d’avantages adaptés à l’entreprise avec les justifications nécessaires et
une vaste compréhension ainsi qu’un engagement de l’entreprise.
Définition
Le troisième élément de la vision d’entreprise SOA, le « quoi », est
tout aussi important que le « pourquoi » (avantages). Une définition de la SOA permet de formuler l’architecture spécifique à l’entreprise et
d’identifier les aspects requis.
37
SOA for Profit
Comme c’est le cas pour les expressions telles qu’architecture d’entreprise et
gouvernance informatique, il existe une multitude de définitions pour le
concept d’« architecture orientée services ». Il importe peu d’identifier la
bonne, mais il convient plutôt de déterminer celle qui est la mieux adaptée à
votre entreprise. Il y a lieu d’adopter un jugement en fonction des objectifs
de la SOA et de la définition la plus adéquate. La Figure 2.5 présente un certain nombre de définitions de la SOA.
Gartner:
L'architecture
orientée services
(SOA) est une
approche de
conception de
logiciel client/serveur
dans laquelle une
application se
compose de services
logiciels et de
consommateurs de
service logiciel
(également appelés
clients ou demandeurs de service)
CBDI:
Politiques, pratiques,
cadres permettant
de fournir et d'utiliser
la fonctionnalité
d'application en tant
qu'ensembles de
services publiés à un
niveau de granularité
adapté aux
consommateurs de
services. Les services
peuvent être
demandés, publiés et
découverts et sont
extraits de la mise en
œuvre au moyen
d'une forme simple
et standard
d'interface.
W3C:
Ensemble de
composants pouvant
être demandés et
dont les descriptions
d'interface peuvent
être publiées et
découvertes.
Bieberstein et al:
Cadre pour
l'intégration des
processus métiers et
le support de
l'infrastructure
informatique en tant
que composants –
services – sûrs et
standardisés
pouvant être
réutilisés et combinés
afin de traiter les
changements de
priorité de
l'entreprise.
Figure 2.5 : Définitions de la SOA
Conséquences
Outre les avantages, le choix d’une SOA entraîne également un
certain nombre de conséquences. Il est important de disposer
d’une vue d’ensemble de ces conséquences très tôt dans le processus de
prise de décision car elles détermineront pour une large part le succès et le
niveau d’investissement au sein de l’entreprise.
En pratique, chaque conséquence d’une SOA entraîne un investissement. Et,
comme pour tout changement, il existe des coûts qui y sont associés.
38
2 J’en veux pour mon argent
Les conséquences ordinaires de la mise en œuvre de la SOA sont les suivantes :
•
Focalisation accrue sur l’effort centré sur le processus.
•
Changement des processus de gouvernance et des processus architecturaux.
•
Changement du processus de développement de l’activité.
•
Changement du processus de développement de l’informatique.
•
Changement des processus d’administration et de maintenance.
•
Nécessité d’une formation nouvelle pour le personnel informatique.
•
Nécessité d’une formation nouvelle pour les interlocuteurs métiers.
•
Nécessité de nouveaux outils.
Nous discuterons ultérieurement plus en détail de ces conséquences liées à
la mise en œuvre de la SOA. Au moment de définir la vision d’entreprise, il
est important d’identifier et de détailler toutes les conséquences pertinentes
afin de prendre une décision éclairée sur la capacité de l’entreprise à les
supporter.
Mise en œuvre
Le cinquième et dernier élément de la vision d’entreprise est la
mise en œuvre. La mise en œuvre de la SOA est traitée en termes
généraux. Elle n’est pas un processus linéaire puisque des mises en œuvre
multiples et simultanées sont possibles. Il est important de souligner dans ce
chapitre les structures de financement, d’initiation, de mise en œuvre et de
gestion.
Afin de mieux comprendre ce que peut offrir la SOA, un certain nombre
d’exemples d’applications sont inclus dans ce chapitre sur la mise en
œuvre.
Comme nous l’avons vu plus haut, la définition d’une vision d’entreprise
constitue un processus. La prise de conscience et l’acceptation de la SOA au
sein d’une entreprise peuvent être fortement accrues en impliquant dans ce
processus les parties prenantes concernées, tels que gestionnaires de processus, chefs de service informatique, administrateurs et architectes. Un atelier
de méthodologie convient parfaitement pour la création d’une vision d’entreprise. Différentes personnes œuvrant dans différentes disciplines peuvent
être amenées à travailler ensemble pour un objectif commun.
39
SOA for Profit
La définition d’une vision d’entreprise peut être encore facilitée en impliquant des consultants capables d’établir un lien entre les concepts SOA et les
défis commerciaux de l’entreprise.
Outre les avantages mentionnés plus haut, une vision d’entreprise est un
excellent moyen d’annoncer le message SOA au sein de votre entreprise au
cours de nombreuses étapes de communication.
Vous vous demandez peut être pourquoi aucun business case n’est établi
pour la SOA. Il existe un certain nombre de raisons pour lesquelles nous n’y
sommes pas favorables. La principale est que la SOA ne doit pas devenir un
objectif en soi. La SOA est un style d’architecture parfaitement adapté à une
entreprise qui a besoin de faire face à de multiples changements. Nous
conseillons de réaliser des business cases pour ces changements, tels que
l’amélioration des processus et l’introduction d’un nouveau produit sur le
marché. Autre raison pour ne pas établir un business case pour la SOA : il est
impossible de calculer les effets de la SOA sur la rentabilité d’une entreprise.
En effet, plusieurs facteurs ont une incidence sur la rentabilité et il est
impossible d’isoler l’effet de la SOA. La troisième et dernière raison est que
la mise en œuvre de la SOA s’assimile à un véritable voyage. Au début du
voyage, vous savez où vous voulez aller, mais votre itinéraire exact n’est pas
encore clairement déterminé. Ce n’est qu’à l’issue de la première étape que
vous percevez mieux la suivante. Pour résumer, il est impossible de tracer à
l’avance un chemin précisément défini. La SOA n’est pas une révolution, sa
mise en œuvre n’implique pas de big-bang. La SOA tient plus de l’évolution :
la mise en œuvre de la SOA peut être réalisée petit à petit, chaque étape
apportant une valeur ajoutée.
Afin de déterminer l’objectif que vous souhaitez atteindre avec la SOA, nous
vous conseillons d’élaborer une vision d’entreprise SOA. Non seulement cela
vous permettra de clarifier vos objectifs, mais cela vous indiquera si vous
devez ou non entreprendre ce voyage et, le cas échéant, ce que vous devez
emmener avec vous. Ensuite, vous pourrez planifier la première étape SOA
en vous concentrant sur un problème commercial concret. Vous pourrez pour
cela élaborer un business case, ce qui vous forcera également à mettre en
œuvre la SOA là où l’urgence est la plus grande.
40
2 J’en veux pour mon argent
2.5 Dans quels cas la SOA n’est-elle pas recommandée pour moi ?
La SOA doit être envisagée sur le long terme. Un nombre croissant de fournisseurs et d’organisations d’utilisateurs finaux importants appliquent la
SOA. Cela signifie que de plus en plus de logiciels et de matériel s’appuient
sur cette architecture orientée services, qu’un nombre croissant de fonctionnalités sont proposées en tant que services, et que de plus en plus de chaînes
et d’efforts coopératifs sont structurés selon une méthode fondée sur le service. Tôt ou tard, il deviendra donc impossible d’y échapper.
Reste à savoir si vous devez anticiper la SOA ou bien si vous devez simplement attendre que la SOA vous prenne de vitesse. La SOA est particulièrement adaptée à une entreprise dotée d’une informatique hétérogène devant
faire face à de nombreux changements. Toutes les entreprises classées au
Fortune-500 entrent dans cette catégorie. Les entreprises fortement dépendantes de l’informatique, telles que les banques, compagnies d’assurance et
sociétés de télécommunication, en font notamment partie. Il leur est conseillé
de mener un dialogue stratégique sur la SOA et de l’enregistrer dans une
vision d’entreprise SOA.
À l’autre extrémité du spectre, on trouve des entreprises dotées d’une informatique homogène et connaissant relativement peu de changement. Pour ces
entreprises, le gain résultant de la mise en œuvre de la SOA reste discutable. Par
exemple, une petite entreprise industrielle fonctionnant presque exclusivement
avec SAP tirera sans doute davantage de bénéfices d’une stratégie SAP.
Il est intéressant de noter qu’il peut exister des départements ou fonctions au
sein de l’entreprise dont les exigences en termes d’informatique sont radicalement différentes. Ceci a par conséquent un impact sur le choix de SOA
possible. En général, la SOA est moins adaptée dans le cas d’une informatique
homogène, lorsque la réalisation en temps réel est extrêmement importante
et lorsqu’il n’y a pas de véritable changement substantiel.
2.6 Synthèse
Il doit être clair que la mise en œuvre de la SOA peut être financièrement
rémunératrice pour une entreprise. En effet, il est possible de gagner de l’argent grâce à une utilisation plus efficace de l’informatique et à une activité
plus souple permettant d’innover et d’apporter des améliorations plus rapi-
41
SOA for Profit
dement. Au quotidien, la SOA a souvent tenu ses promesses, qu’elles aient été
mises en œuvre du fait de considérations stratégiques ou qu’elles aient été
dictées par la nécessité.
Il est important de comprendre que la SOA n’est pas une fin en soi. C’est un
moyen d’apporter souplesse et rentabilité à l’entreprise. La formulation d’une
vision d’entreprise SOA est donc une première étape essentielle dans l’exploration des possibilités de la SOA pour votre entreprise. Ce type de vision
d’entreprise se compose de cinq éléments (raisons, avantages, définition,
conséquences et mise en œuvre) et constitue un outil puissant pour vous
aider à gagner de l’argent grâce à une approche SOA.
42
3
L’essence de la SOA en sept concepts de
base
3.1 Introduction
La SOA est simple. Les concepts fondamentaux de la SOA sont facilement
compréhensibles, même si l’on est peu familiarisé avec l’informatique. La SOA
relève en grande partie du bon sens, d’une façon de raisonner intelligemment
et peut-être… du désir aveugle de croire. Dans un monde nouveau, l’architecture orientée services représente la façon la plus logique et pratique de faire
de l’informatique. Malheureusement, les vraies innovations sont rares dans le
secteur informatique. Pour en tirer profit, ou simplement pour décider si votre
entreprise peut en bénéficier, une définition claire de la SOA s’impose.
Dans le présent chapitre, nous aborderons la perception de la SOA et expliquerons ce qu’est exactement cette architecture, en utilisant des termes aussi
vieux que l’informatique, voire encore plus anciens.
Si les concepts en tant que tels peuvent sembler simples, changer la relation
de votre entreprise avec l’informatique prendra du temps : la transition vers
l’architecture orientée services interviendra progressivement, mais son incidence au niveau commercial et informatique sera considérable.
3.2 Perception de la SOA
L’un des défis majeurs que rencontrent les entreprises lorsqu’elles adoptent
la SOA consiste à réunir assez de connaissances sur ce sujet pour distinguer
la valeur réelle, les défis concrets et la démarche à suivre la plus rentable.
Réunir des informations s’avère un défi en soi. L’architecture orientée services
n’a pas été inventée par une seule entreprise. Il n’existe pas d’organisme de
normalisation habilité à définir ce qu’est la SOA. De même il n’existe que peu,
voire aucun consensus sur ce qui permet de qualifier une architecture donnée
d’« architecture orientée services ». Nombre d’entreprises du secteur informatique ont développé leur propre vision de la SOA, parfaitement adaptée à leurs
gammes de produits ou de services. Même les plus grands visionnaires en la
matière, tels que Gartner et Forrester, des experts en SOA ou encore le forum
43
SOA for Profit
CBDI (Component Based Development Integration), utilisent tous une terminologie et des modèles différents. Tout ceci trouble considérablement la situation, et complique le problème au lieu de lui trouver une solution.
Cependant, la perception que les professionnels de l’informatique ont de la
SOA est bien plus large qu’une simple architecture orientée sur des services.
La SOA est désormais synonyme d’« utilisation correcte de l’informatique »
dans son interprétation la plus large. La SOA est la prochaine étape en matière
de processus de maturation de l’informatique, ou plutôt la prochaine étape
en matière d’informatique telle qu’elle devrait être utilisée par les entreprises.
Toutes les initiatives précédentes se sont alignées de près ou de loin à une
perception floue de la SOA. Lorsque l’on parle d’architecture orientée services, il existe une convergence des règles de pratique d’excellence et de
concepts prouvés en matière d’architecture, de développement logiciel, de
gouvernance, d’alignement et de technologie.
3.3 C’est le bon moment
Comment la SOA est-elle parvenue à s’imposer ? Pourquoi a-t-elle suscité un
intérêt aussi rapide ? Les raisons sont multiples. La conjonction de divers
développements a provoqué cet intérêt considérable, ainsi que la naissance
de nouvelles perceptions concernant le travail des entreprises avec l’Internet.
Premièrement, des initiatives technologiques sont apparues en matière d’intégration de systèmes et de services Web ; deuxièmement, l’utilisation de l’Internet a atteint un seuil critique ; et enfin, sans doute la raison la plus importante, les entreprises ont exercé une pression considérable sur l’informatique
pour réduire le coût total de possession et pour garantir une plus grande
performance et fiabilité. Suite à l’intérêt suscité par la SOA, l’adoption rapide
par des fournisseurs de logiciels a provoqué une augmentation de la présence
du terme SOA dans le milieu du marketing et des ventes, contribuant à sa
popularité. À partir de la technologie, la valeur réelle de la SOA est devenue
limpide, ainsi que l’impact potentiellement positif sur les marchés.
Ceci étant, elle n’implique pas uniquement le monde du marketing et des
ventes. La raison pour laquelle la SOA a été acceptée et introduite dans des
entreprises de plus en plus nombreuses tient au fait qu’il s’agit d’un modèle
clair qui s’attaque à des problèmes informatiques réels. C’est la « bonne
façon » de pratiquer l’informatique et les gens le « ressentent » ainsi. Tout cela
parce que les concepts de base de la SOA sont simples et bien connus.
44
3 L’essence de la SOA en sept concepts de base
3.4 Les sept concepts de base de la SOA
En nous appuyant sur plus de 40 années d’expérience pratique dans le
domaine informatique, nous pouvons désormais affirmer qu’il existe certaines
façons d’assurer une utilisation correcte de l’informatique. En appliquant ces
méthodes, vous auriez fini par « inventer » vous aussi la SOA. En effet, nombre d’entreprises utilisent les principes SOA depuis de nombreuses années
et ce, avant même que le terme SOA ne soit apparu.
Les concepts de base sont les suivants :
1. Subdiviser
Pour éviter tout désordre, il faut naturellement regrouper les éléments
entre eux et définir des composants.
2. Convenir de la méthode
Dans le monde des affaires, vous devez certainement vous mettre d’accord
avec le personnel sur la façon de travailler ensemble, convenir de la livraison avec les fournisseurs, etc.
3. Utiliser l’existant
Avant d’acheter quelque chose de neuf, vous vérifiez préalablement si
quelque chose que vous possédez déjà peut convenir.
4. Passer du sur mesure à l’infrastructure
Si une solution toute faite et adaptée existe déjà, mieux vaut l’utiliser plutôt
que d’en créer une nouvelle spécifiquement pour vous.
5. Faciliter le changement, s’améliorer en continu
La seule chose qui ne changera jamais c’est le changement. Donc, vous
vous attendez certainement à ce que tôt ou tard les choses changent.
6. Changer pour une raison commerciale
Quand vous investissez, vous voulez savoir ce que vous obtiendrez en
retour.
7. Réagir à l’environnement
Outre sa ressemblance avec le concept de « faciliter le changement », réagir à l’environnement relève de l’activité quotidienne. Si quelque chose se
produit, votre réaction doit servir au mieux l’entreprise.
Nous allons maintenant tenter de démontrer que ces concepts sont l’essence
même de la SOA. Au cours de l’explication, nous nous plongerons dans des
notions telles que l’Enterprise Service Bus (ESB, Bus de Services d’Entreprise), l’organisation en couches, l’architecture événementielle, et quelques
abréviations courantes dans l’approche SOA.
45
SOA for Profit
3.4.1 Concept de base 1 : Subdiviser
L’aspect de la SOA le plus communément admis est le fait que l’architecture
orientée services est constituée de services. D’un point de vue informatique,
des services représentent de petits blocs de traitement qui peuvent être sollicités pour effectuer des tâches. D’un point de vue commercial, un service est
« quelque chose que nous effectuons afin d’ajouter de la valeur », en s’appuyant sans doute sur l’informatique. Grâce à la SOA, les deux points de vue
se rejoignent : un service devient un petit bloc de traitement qui peut être
sollicité pour assister une action commerciale afin d’ajouter de la valeur.
Si l’on considère l’informatique de manière générale en tant que support de
processus métiers, il existe des raisons évidentes de vouloir procéder à une
subdivision. Nul ne souhaite disposer d’un ensemble technologique informe
et difficile à comprendre et à entretenir. Il n’est pas souhaitable que tout soit
enchevêtré de telle sorte qu’il soit impossible de changer un élément sans
affecter tout ou partie de l’ensemble. Enfin, il existe une raison très pragmatique à la subdivision : il est impossible de créer un grand système capable de
supporter la totalité de votre entreprise.
Pour aborder au mieux ce besoin de subdivision, l’informatique basée sur la
SOA aura, par définition, deux propriétés :
•
Les services sont aussi indépendants les uns des autres que possible.
•
Les services sont définis en termes judicieux pour toute activité commerciale.
Les services sont aussi indépendants les uns des autres que possible
Ici, « indépendant » renvoie à l’indépendance de conception, mais également
à l’indépendance de fonctionnement. L’indépendance de conception nous
offre la possibilité de remplacer un service sans nécessairement devoir remplacer tous les autres. Une telle indépendance est possible en concevant des
services qui peuvent fonctionner sans s’appuyer les uns sur les autres, ou
bien, lorsque la dépendance est importante, en définissant entre ces deux
services un lien souple que ne peuvent briser des changements mineurs. Dans
ce cas, le XML, format extensible et souple pour l’envoi de données, est parfaitement adapté.
L’indépendance de fonctionnement est réalisable en tentant d’être aussi
asynchrone que possible : les services ne s’attendent plus entre eux pour
terminer un traitement, mais « attendent des instructions » pour effectuer une
tâche. Un service effectue une part du traitement, puis fait suivre les résultats
46
3 L’essence de la SOA en sept concepts de base
à un autre service qui à son tour assure sa part du traitement. Une fois qu’une
partie du traitement est effectuée, le service « oublie » tout et se tient prêt à
gérer une autre demande ou un autre appel. C’est une méthode de travail
similaire à celle des contrôleurs aériens : si un avion est « dans leur domaine
de surveillance », ils en connaissent les moindres détails, garantissent sa
sécurité, et le guident dans l’espace aérien. Une fois qu’un avion passe une
limite ou se rapproche d’un aéroport, son contrôle incombe à un autre contrôleur. Le premier contrôleur « oublie » alors l’avion et est prêt à en gérer un
autre. Rendre la SOA aussi asynchrone que possible représente une différence considérable avec les moyens de traitement performants traditionnels
dits « en ligne ». Cette indépendance entre les services est fréquemment
décrite par l’expression « configuration dispersée ».
Il existe un défi considérable dans la conception d’architecture orientée services : définir des services de configuration dispersée qui restent néanmoins
suffisamment en cohésion pour qu’il soit possible de former facilement des
processus complexes.
Les services sont définis en termes judicieux pour toute activité
commerciale
Lorsque l’on songe aux services, une question importante se pose qui est
intimement liée à la SOA : comment déterminer l’envergure des services et
des parties du système ? Comment les définir ?
Il y a beaucoup à dire concernant le « comment », mais il existe une règle de
pratique d’excellence très importante utilisée pour définir des services : un
service devrait avoir une signification pour l’activité de l’entreprise. D’une certaine manière, l’informatique est une abstraction technologique de l’entreprise
qu’elle assiste. Un processus commercial est soutenu par des processus techniques, une action commerciale a pour conséquence des actions informatiques
qui se mettent en place. Plus cette abstraction ressemble à la réalité, mieux elle
s’adapte aux mouvements et au fonctionnement de l’entreprise. Grâce à la SOA,
nous considérons la division de toute l’informatique de telle sorte qu’elle renvoie une image de l’activité commerciale la plus fidèle possible.
Cela peut paraître simple, mais ne fonctionne pas totalement. Au niveau le
plus bas, l’informatique se traduit toujours par des parties de code exécutées
sur une machine. À ce niveau-là, il peut être difficile d’identifier le processus
commercial en cours d’exécution. Il faut admettre que certains services sont
également trop techniques pour avoir un sens en termes commerciaux, ce qui
47
SOA for Profit
nous amène à la découverte de multiples couches dans la SOA, au même titre
qu’il existait des couches dans les modèles architecturaux antérieurs de serveurs client ou d’application Internet. L’informatique se constitue de différents niveaux, dont le plus élevé est le « niveau managérial », et dont le plus
bas se rapporte au matériel informatique et au code de bas niveau.
En résumé : l’architecture orientée services est une architecture dans laquelle
nous nous efforçons de créer des services qui ont une signification pour une
entreprise et sont de configuration dispersée.
3.4.2 Concept de base 2 : Convenir de la méthode
La collaboration avec des partenaires, différents départements et des clients
demande beaucoup de travail. Tous les groupes ont des besoins divers et des
attentes qui varient en termes d’objectifs. Ils veulent tous réaliser des choses
différentes pour vous ou votre entreprise. L’intégration n’est pas simple.
Dans un environnement informatique typique, de nombreux systèmes différents sont utilisés pour soutenir l’activité quotidienne. Lors de l’intégration
ou de la communication à un niveau commercial, les systèmes sous-jacents
devront également être intégrés ou commencer à communiquer. Une fois de
plus, nous voyons que l’informatique donne une image de l’aspect managérial
d’une entreprise. Le travail à effectuer à un niveau commercial sera réalisé
également au niveau informatique.
L’intégration d’applications d’entreprise (EAI, Enterprise Application Integration) est un concept légèrement plus ancien que la SOA. Comme dans le
cas de la SOA, l’EAI est un terme vague devenu à la mode et qui a été inventé
pour les mêmes raisons qui président aujourd’hui à l’apparition de la SOA.
L’objectif principal de l’EAI est d’intégrer toute l’informatique en un seul
élément, afin d’être plus souple et efficace.
L’architecture orientée services utilise nombre de règles de pratique d’excellence développées dans le domaine de l’EAI. Les plus remarquables d’entre
elles sont deux réalisations importantes incorporées dans toute réussite de la
SOA :
•
Normes
•
Intégration de données
48
3 L’essence de la SOA en sept concepts de base
L’importance des normes
Les accords sont des arrangements entre deux parties ou plus. Pour l’utilisation de logiciels, plus le nombre de parties adhérant à un accord est important,
mieux c’est. Vous avez moins de chance de vous retrouver pris au piège par
la méthode de résolution d’un problème appliquée par un fournisseur. Un
accord devient une « norme » lorsqu’un nombre suffisant de parties s’accorde
à utiliser la même solution ou approche, ou lorsqu’une partie qui fait autorité
déclare que cette solution ou approche constitue une « norme ». Au niveau
technique, il peut s’agir d’un accord sur la manière dont les messages parcourant le réseau devraient être écrits ; à un niveau plus élevé, il peut s’agir d’un
accord sur la manière de trouver des services disponibles au sein de votre
réseau. D’autres normes méthodologiques également, telles que le Rational
Unified Process ou des méthodes de gestion de projets, s’avèrent importantes
lors du choix des outils de support ou dans le cadre du recrutement de salariés disposant des compétences précises.
Il est également possible de mettre en œuvre des normes au sein d’une société
ou au sein d’un groupe de partenaires travaillant de concert. Par exemple, les
gros détaillants ont décrit la façon dont les fournisseurs doivent (!) fournir
des informations quant à leurs produits : en recommandant les messages et
la façon dont les messages doivent être livrés.
L’importance de l’intégration de données
Premièrement, qu’entendons-nous par « intégration » de données ? Ce
concept est très ancien et consiste essentiellement à se mettre d’accord sur
des significations. Si, dans un recoin d’une organisation, on attribue un
numéro d’identification à une commande, tous les systèmes et départements
reconnaissent-ils le même numéro ? Si un département rapporte un profit,
peut-on directement le comparer au profit d’un autre département, ou le
premier département inclut-il également différents frais ? Pour pouvoir traduire des données d’un département à un autre, il faut connaître le rapport
qui les lie. À cet égard, il faut noter qu’il s’agit là d’une question de management qui doit être élucidée, et mise en œuvre dans la technologie qui effectue
l’intégration et/ou la traduction à proprement parler.
Dans les limites d’une entreprise, cela peut déjà constituer une gageure, en
particulier pour les grandes multinationales. Pour viser à l’unité en termes de
compréhension des données au sein des entreprises, des normes industrielles
émergent, essayant de définir une terminologie commune à utiliser lors de
l’envoi d’informations entre les services au sein de diverses entreprises.
49
SOA for Profit
Une fois de plus, il n’y a rien de nouveau concernant les normes industrielles
en cours de développement (souvenez-vous d’EDIFACT ou SWIFT), mais
avec la SOA, les avantages des normes sont bien plus nombreux.
L’intégration de données financières est sensiblement simplifiée par des
règlementations nouvelles en matière de reporting. À ce titre, SarbanesOxley introduit, dans une certaine mesure, une norme de reporting prescrite
par la loi.
3.4.3 Concept de base 3 : Utiliser l’existant
Avant de créer du neuf, il y a lieu de vérifier si certains éléments dont vous
disposez déjà pourraient répondre à votre besoin. Ou bien, dans une perspective légèrement différente, il convient de s’assurer que deux départements ne
font pas, de près ou de loin, la même chose, car alors un seul département
suffirait. Ce concept s’applique également au domaine informatique : nous
nous évertuons sans cesse à n’effectuer une tâche qu’une seule fois. Avec la
SOA, nous allons plus loin afin de déterminer les éléments informatiques
normalement mis en œuvre plusieurs fois, alors que nous pouvons désormais
les mettre en place une seule fois.
Les avantages d’une redondance limitée sont intéressants :
•
moins de maintenance technologique, donc moindres frais. Cet avantage
est particulièrement intéressant si vous considérez qu’une très large part
des budgets informatiques est actuellement consacrée à la maintenance
de l’existant et non pas à l’innovation.
•
moins de technologie signifie également que des changements peuvent
s’opérer plus facilement, permettant ainsi une plus grande réactivité informatique face aux demandes changeantes du marché, en vue d’accroître
« l’agilité » de l’informatique.
•
baisse générale : dépenses en matériel informatique, frais de licence,
bogues et erreurs, compétences à entretenir, etc.
D’anciennes initiatives telles que l’orientation objet ou le développement par
composants logiciels ont ouvert la voie au concept de réutilisation : l’expérience nous dit qu’il est impossible que les composants réutilisables soient
négligeables, et que chacun, du management au service informatique, doit
pouvoir aisément réutiliser un composant.
50
3 L’essence de la SOA en sept concepts de base
Réutilisation de service
Si les services sont bien conçus et de configuration dispersée, leur réutilisation
est simple. Pour que la réutilisation soit possible, un service doit fournir des
résultats prévisibles (faire ce qu’il est censé faire) quelle que soit la façon dont
il est sollicité (c’est ce que l’on appelle l’« indépendance du contexte »). À titre
d’exemple, un service qui assure le support de l’enregistrement d’un sinistre
pour une compagnie d’assurance n’est véritablement réutilisable que dans la
mesure où ce même service peut être utilisé lors d’enregistrement par téléphone, par e-mail, via un intermédiaire ou directement par Internet. Si le service
réagit différemment à chaque situation, la réutilisation est limitée, voire nulle.
Comment atteindre l’objectif de la réutilisation
La SOA permet la réutilisation de services. Pour pouvoir véritablement mettre
en place la réutilisation dans votre entreprise, la SOA ne sera pas suffisante.
Une démarche de gestion appropriée et une économie adaptée aux projets
ainsi que des services réutilisables doivent être créés pour permettre à la
réutilisation de décoller véritablement.
Plus d’une façon de réutiliser
Dans la plupart des discussions, la réutilisation se concentre sur le type le plus
élémentaire de réutilisation : utiliser un service dans des processus métiers
multiples. Si cette méthode de réutilisation est intéressante, d’autres méthodes
existent, qui ont plus de chances de se présenter et sont sans doute plus rentables. Afin d’expliquer cette nouvelle vision de la réutilisation, nous allons
présenter le concept de base « passer du sur mesure à l’infrastructure ».
3.4.4 Concept de base 4 : Passer du sur mesure à l’infrastructure
Au tout début de l’informatique, les programmateurs avaient beaucoup à faire.
Même la tâche la plus simple devait être codée manuellement. Lire un fichier
à partir d’une disquette ? Programmez-le vous-même ! Faire apparaître un
texte sur un écran ? Programmez-le vous-même ! Stocker des données quelque part pour les récupérer plus tard ? Programmez-le vous-même !
De nos jours, il serait inimaginable d’écrire des logiciels effectuant des actions
apparentées aux bases de données. Il en va de même pour bien d’autres éléments de base qui constituent l’outillage des développeurs de logiciels : des
portails Internet à la gestion utilisateur, des courriers électroniques au vérificateur d’orthographe. Tout ceci est disponible dès la création des logiciels.
51
SOA for Profit
Le fait qu’une industrie entière adopte une architecture commune telle que
la SOA a pour conséquence que les outils et l’assistance peuvent être conçus
pour aborder certaines parties de l’architecture. Un nouvel outillage devient
disponible pour prendre en charge le transport de messages, pour la sécurité
et pour toutes sortes d’autres fonctionnalités générales. De nouvelles couches
d’infrastructure sont disponibles, au même titre que des logiciels de base de
données sont devenus des « infrastructures ».
Dans une certaine mesure, il s’agit d’une règle de bonne pratique connue sous
le nom de « buy before build » ou « achat avant fabrication ». Dans le contexte
de la SOA, cette règle devrait être rebaptisée « buy before re-use before
build », ou « achat avant réutilisation avant fabrication ». Notez l’ordre des
mots « achat » et « réutilisation ». Cela signifie que : si un certain outil est
disponible sur le marché pour répondre à un besoin, mieux vaut l’utiliser que
de réutiliser un service existant. Il y a une raison à cela : les frais de maintenance sont réduits, voire inexistants pour un service acheté : la plus grande
partie de la maintenance voire son intégralité est effectuée par le fournisseur.
Avec une véritable SOA, il existe également l’option d’acheter un service en
tant que service : ne pas acheter le logiciel à installer sur vos propres machines et obtenir l’assistance de votre propre personnel, mais préférer externaliser le service en s’accordant simplement sur le niveau de service à fournir.
La réduction des frais de maintenance informatique permettra une amélioration immédiate du coût total de possession.
En ce sens, une entreprise finira par permettre la croissance d’une « infra­
structure » de services qui pourra être utilisée par quiconque au sein de la
société pour effectuer des tâches nouvelles ou existantes. Il s’agira d’un
groupe important de services « simplement disponibles » parmi lesquels choisir lors de différents projets. Il convient de noter que, dès lors, un « projet »
deviendra plus petit, car la création de services demandera moins d’efforts.
Des projets plus petits rendent la commercialisation plus rapide, ce qui aura
un impact sur la façon dont l’entreprise utilise l’informatique. Il sera peutêtre possible de « simplement faire des essais » pour voir si des avantages en
découlent : si l’utilisation d’un nouveau processus est rapide et bon marché,
pourquoi ne pas voir s’il fonctionne comme prévu !
Ambition durable de l’informatique : le développement agile, en interaction
avec le marché, devient accessible.
52
3 L’essence de la SOA en sept concepts de base
Réutilisation et services d’infrastructure
Pour illustrer les différentes façons de penser la réutilisation, nous avons pris l’exemple d’un hôpital où les services peuvent être utilisés pour des opérations quotidiennes
de prise en charge de patients.
Dans une situation de la vie réelle, dans laquelle différents services ont choisi leur
propre système, comme le montre la Figure 3.1, ces systèmes travaillent difficilement
ensemble. Bien que ces systèmes reflètent la structure organisationnelle et qu’il existe
quelques décalages, certains éléments se chevauchent : redondance de données,
entrée manuelle de données, doubles entrées, etc.
Maternité
Soins
intensifs
Enregistrement
Patient
RH
Labo IRM
Figure 3.1 : Situation traditionnelle
Grâce à la SOA, comme l’illustre la Figure 3.2, l’informatique qui assiste l’activité est
plus cohérente et solide. Les services sont directement reliés aux capacités métier et
peuvent être réutilisés dans différents projets, processus et partout dans l’organisation. Toutes les informations ne seront entrées qu’une seule fois et sont accessibles
partout où cela est nécessaire.
…
…
…
…
Enregistrement patient
Diagnostic
Médication
Opération
Régime et alimentation
Réutilisation
Figure 3.2 : Services métiers
53
SOA for Profit
La SOA effectue également la réutilisation en isolant des services communs nécessaires
dans plusieurs services métiers différents. Ces services communs, présentés sur la Figure
3.3, peuvent être mis en œuvre par la suite au moyen d’outils standards permettant
ainsi un développement plus rapide et la réduction des frais de maintenance.
Sécurité
Autorisations
Transformation
Réutilisation
Journalisation
…
Figure 3.3 : Services techniques
Les services métiers se composent de services techniques, parfois améliorés par des
programmations ou configurations spécifiques. Cela a peu d’influence sur l’activité,
tant que le services métiers peut être utilisé pour assister directement les fonctions
métier. Cela recouvre notamment des services techniques, des applications patrimoniales, des systèmes GRC existants, etc.
La vision d’ensemble se trouve en Figure 3.4.
Processus métiers
Les processus peuvent être reconfigurés à volonté en
réutilisant des services métiers sous-jacents. Les étapes
de processus peuvent être assistées par un ou plusieurs
services. Un service métiers peut assister un ou
plusieurs processus, une ou plusieurs étapes de
processus.
Services métiers
Ces services peuvent se composer de services
techniques et de services transversaux (tels que les
services de sécurité). Un service métiers connaît une
pertinence commerciale claire et compréhensible des
personnes évoluant dans la sphère commerciale.
Services techniques
Les services techniques peuvent être la mise en œuvre
de parties d'un service métiers, ou une interface de
service d'une application existante. En réalité, les
services techniques en soi peuvent également se
composer d'autres services techniques ; ce qui signifie
qu'il peut y avoir plusieurs couches de réutilisation.
Application Application
patrimoniale patrimoniale
Couches technologiques
Sous tous les services, se trouve une couche de matériel
informatique et de logiciels d’infrastructure tels que des
services d'application et des serveurs de base de
données. Grâce à la virtualisation, cette dépendance
devient moins étroite.
Figure 3.4 : Services et couches dans l’architecture orientée services
54
3 L’essence de la SOA en sept concepts de base
Destruction proactive
À l’instar de la réutilisation en général, rien ne se fait automatiquement. Pour
une véritable optimisation de l’ensemble des services que regroupe l’entreprise, il est conseillé d’effectuer une vérification régulière pour s’assurer que
les services, dont vous avez en charge la maintenance, sont actuellement disponibles sur le marché. Il existe un avantage certain à préférer un service tout
fait bénéficiant d’un support à un service construit et maintenu en interne.
Cette destruction de vos propres services, au profit de services standards, se
nomme « destruction proactive » et, malgré son nom, elle est le signe d’une
organisation informatique et commerciale très mûre.
Défi
Lorsque l’on analyse une entreprise et que l’on détermine les services nécessaires,
l’accent est mis sur la « valeur ajoutée » qu’offre une organisation : si je suis capable de monter mon entreprise dans son intégralité à partir de services fournis par
des tiers, comment puis-je me distinguer de mes concurrents ? Si un concurrent
peut assembler les mêmes services que ceux que j’utilise, quelle différence y aurat-il pour notre utilisateur final ? La distinction peut intervenir à de multiples
niveaux : les mêmes services peuvent être utilisés avec différents paramètres
(règles commerciales différentes), au sein d’un processus différent ou (et c’est le
plus souvent le cas) avec une commercialisation et sous un étiquetage distincts.
3.4.5 Concept de base 5 : Faciliter le changement, s’améliorer en continu
« La seule chose qui ne changera jamais c’est le changement ». Il est difficile de
prédire l’avenir. Toutefois, pour que l’informatique prenne de la valeur, elle doit
s’harmoniser avec l’activité commerciale qu’elle supporte. Pour un ajustement
parfait, maintenant et dans un avenir difficilement prévisible, l’informatique doit
pouvoir évoluer : elle doit pouvoir s’adapter aux circonstances changeantes et
« faciliter le changement commercial ». Faciliter le changement signifie tout simplement répondre aux nouvelles circonstances rapidement et le mieux possible.
Deux ingrédients entrent en jeu : la capacité à changer (l’agilité) et la capacité à
trouver en permanence la solution optimale et à s’améliorer sans cesse.
Les concepts de base de la subdivision et du passage du « sur-mesure » à
l’« infrastructure » contribuent en grande partie à atteindre l’agilité nécessaire. Une caractéristique essentielle de cette agilité est que certains éléments
ne changent pas. Afin d’assembler rapidement des blocs de fabrication, les
blocs eux-mêmes doivent être suffisamment stables.
55
SOA for Profit
L’amélioration permanente se caractérise par des initiatives telles que le
CMM (Capability Maturity Model, modèle d’évolution des capacités) ou Six
Sigma. Même le modèle ITIL (Information Technology Infrastructure Library,
Bibliothèque des Infrastructures des Technologies de l’Information), la bibliothèque commune des pratiques pour l’assistance d’infrastructure comprend
un processus d’optimisation. Grâce à la SOA, le développement de logiciels,
l’utilisation de méthodes de conception et l’utilisation plus importante de
services réutilisables s’accordent parfaitement avec une approche d’amélioration de processus. Avec la SOA, en conjonction avec des méthodes de développement de logiciel de type industriel, l’informatique peut commencer à
automatiser ses propres processus, augmentant ainsi la productivité, réduisant les risques d’erreurs et intégrant de la connaissance dans les processus
et l’outillage.
3.4.6 Concept de base 6 : Changer pour une raison commerciale
La relation entre l’informatique et l’activité commerciale a toujours été délicate. Lorsqu’un projet est trop long à terminer, il est difficile de rester en
phase avec l’évolution des exigences du marché. La dérive dans les objectifs
est monnaie courante, car l’entreprise ne s’arrête pas de penser une fois qu’un
projet a commencé. S’il est une chose que l’on a appris au fil du temps, c’est
que la « réussite » de l’informatique se mesure uniquement par rapport aux
objectifs commerciaux atteints. Si, pour l’informatique, la gestion des attentes
a pris de l’importance, la livraison de solutions requises par l’activité est
encore plus importante.
Grâce à la SOA, nous avons abordé ces questions : augmenter l’agilité pour
livrer plus rapidement et pour développer des logiciels qui, par définition,
sont en accord avec l’activité.
Traditionnellement, les applications développées sont définies par les limites
organisationnelles : par département, par produit ou par ce qui est disponible
sur le marché. Cela signifie que les gens dans des processus réels utilisent
régulièrement plusieurs systèmes pour répondre à une seule demande ou
finir un seul processus. Chercher quelque chose dans un système, changer
quelque chose dans un autre et en faire un compte rendu dans un troisième.
La situation est loin d’être idéale. C’est également pour cette raison que l’EAI
a été convoitée depuis de nombreuses années.
56
3 L’essence de la SOA en sept concepts de base
Grâce à la SOA, on a finalement pu y parvenir : en définissant des services
qui assistent des fonctions (« potentiels ») réelles. Ces fonctions métier resteront suffisamment stables dans les années à venir, seront reliées directement au domaine d’activité et dépendent largement moins de l’organisation
interne d’une société. La propriété est logiquement attribuée à l’unité commerciale ou aux personnes offrant la fonction commerciale. En raison de cette
relation commerciale directe, les services peuvent être regroupés afin d’offrir
des fonctions commerciales plus complexes, au même titre que des unités
multiples peuvent travailler ensemble pour fournir des services plus complexes à la clientèle ou aux partenaires.
Dans un sens, le modèle de « services » d’unités fournissant un service derrière une interface bien définie pourrait également s’appliquer à la partie
humaine des entreprises (en arrivant ainsi à l’entreprise orientée service,
Service Oriented Enterprise). Un schéma semblable à l’utilisation de courriers électroniques pour envoyer des demandes vers différentes unités et
départements se présentera au même titre que lorsque des systèmes informatiques effectuent des services informatiques.
Avec l’émergence de la SOA, une prise de conscience par les informaticiens
de l’importance des facteurs stratégiques métiers et des objectifs d’entreprise
derrière l’informatique est plus forte que jamais. La plupart des aspects
« techniques » sont fournis par de nouvelles couches d’infrastructure et toute
l’attention est dirigée vers les processus métiers, les règles commerciales et
les définitions de services.
Changement du rôle de l’informatique
L’informatique est davantage orientée vers l’aspect business qu’autrefois, ce
qui nous amène à un « alignement » : l’alignement du management et de l’informatique sur les mêmes objectifs. L’alignement en situation réelle n’est pas
simple. Il est déjà difficile pour des unités commerciales de s’aligner et de
communiquer régulièrement entre elles. Il en va de même entre l’activité
commerciale et l’informatique : l’alignement des deux demande beaucoup
d’efforts. Seul un « dialogue stratégique » concernant les objectifs à court et
long terme peut permettre d’anticiper une amélioration dans la collaboration
entre l’activité commerciale et l’informatique.
L’informatique nécessite une vision claire des programmes d’action pour
identifier les services à fournir mais également pour décider de la qualité à
livrer. La SOA nous offre la possibilité d’investir dans des services qui créent
57
SOA for Profit
davantage de valeur et qui sont plus critiques, en faisant en parallèle des
économies sur les services les moins importants. Pour prendre ces décisions,
l’informatique doit connaître les attentes de l’entreprise, ainsi que les évolutions probables du secteur dans un proche avenir. Des stratégies distinctes
entraîneront des choix différents au plan informatique : ainsi, l’internationalisation entraînera de nouvelles langues et devises ; des procédures de rachats
d’entreprises entraîneront une intégration des données et une consolidation
des infrastructures ; de nouveaux produits entraîneront de nouveaux services,
de nouveaux processus et des rapports de gestion plus étendus.
Une fois de plus : la plupart de ces concepts ne sont pas nouveaux. L’orientation métiers a toujours été une pratique des départements informatiques à
succès depuis de nombreuses années, et l’informatique a essayé de faire en
sorte de refléter l’activité lorsque cela était possible. Grâce à la SOA, l’architecture y parvient plus facilement : le support outillage encouragera (presque
naturellement) jusqu’aux programmateurs à se recentrer sur les questions
commerciales, tandis que les services sont une façon claire de diviser l’informatique conformément aux fonctions métiers.
3.4.7 Concept de base 7 : Réagir à l’environnement
L’informatique doit s’adapter à un environnement en mutation ; elle doit faire
preuve d’une agilité dont la demande est très forte aujourd’hui. Au quotidien,
l’informatique doit répondre à un besoin plus important encore : répondre à
ce qui arrive. Lorsqu’un client appelle un centre de service pour passer une
commande, il doit se passer quelque chose au sein de l’entreprise. Si quelqu’un dans l’entrepôt fait tomber accidentellement un conteneur de vases,
une procédure doit être mis en route pour les remplacer avant qu’un client
ne vienne les chercher. Les activités d’aujourd’hui sont mises sous pression
par des clients « finaux » et partenaires pour réagir rapidement aux événements commerciaux. Les délais de livraison se mesurent généralement en
jours ou en heures et non plus en semaines ou en mois. L’utilisation de l’Internet avec sa promesse implicite de « réponse immédiate » aux demandes
ne fait qu’augmenter cette pression. Cela est comparable au passage du courrier papier au courrier électronique : une nouvelle technologie crée de nouvelles attentes.
Tout ceci a une incidence sur la façon dont les gens travaillent au sein d’une
entreprise ainsi que sur l’informatique. L’enregistrement des commandes et
58
3 L’essence de la SOA en sept concepts de base
leur synchronisation dans un lot hebdomadaire ne sont plus possibles. La
vision des stocks doit être exacte au jour près, voire à l’heure ou à la minute
près. La synchronisation à travers une chaîne de valeur comprenant plusieurs
parties ne peut plus s’effectuer par téléphone ou par courrier électronique. Il
faut désormais mettre en œuvre des processus modernes en temps réel. Dans
tous les cas, au même titre qu’une commande en ligne, un changement ou une
demande est pris en compte dès qu’il se présente.
Les avantages sont multiples : la direction peut prendre des décisions commerciales au vu d’informations plus justes, et les clients obtiennent les services qu’ils attendent.
Un élément essentiel de cette meilleure capacité de réaction est l’intégration
de tous les systèmes informatiques compris dans le traitement des événements. D’ordinaire, cela signifie aussi un changement d’architecture : du
concept de « lot » vers celui de l’« architecture événementielle ». De plus, les
services à configuration dispersée peuvent communiquer entre eux comme
ils le décident et peuvent être configurés pour traiter des événements au
moment où ils se présentent.
3.5 Synthèse
Ces concepts de base se recoupent pour constituer une architecture puissante
capable de traiter de nombreux problèmes dans les environnements informatiques actuels. Cette architecture rassemble toutes les meilleures pratiques
mises au point en vue de résoudre des problèmes communs qui se produisent
lors de la conception de technologie pour répondre aux fonctionnements de
toute activité organique et dynamique.
Lorsqu’elle utilise des services clairement subdivisés, créés pour assister de
vrais processus métiers, communiquant au travers de normes précisément
convenues et conçus pour être réutilisables, maintenus et prêts pour l’avenir, l’entreprise peut répondre rapidement aux événements quotidiens et
s’adapter sans problème à de nouveaux marchés et de nouveaux environnements. L’informatique sera alors optimisée pour offrir le meilleur coût
total de possession, et retrouvera son rôle de support et d’inspiration dans
la recherche par l’entreprise de nouvelles et meilleurs opportunités commerciales.
59
SOA for Profit
Il n’est jamais simple de faire adhérer une entreprise à des normes et suivre les
règles des meilleures pratiques. En la matière, la SOA ne diffère par de cette
règle ; mais, avec elle, c’est une question de survie : sans une gouvernance adaptée et une souplesse de mise en œuvre des normes, la SOA créera certainement
un chaos plus important que celui où vous vous trouvez déjà. Par conséquent,
l’enjeu est important et, dans le prochain chapitre, nous aborderons les méthodes de gestion des concepts SOA comme essentiels à la réussite.
60
4
Gouvernance ou chaos
4.1 Introduction
Maintenant que le concept de SOA vous est familier et que vous savez comment en tirer profit, nous allons aborder son mode de mise en place. Quelle
est la principale exigence pour réussir la mise en œuvre d’une approche
SOA ? Quel est le principe numéro un à prendre en compte pour gagner de
l’argent avec la SOA ? Réponse : la gouvernance.
La gouvernance est de loin l’exigence majeure. L’absence de gouvernance
clairement définie conduit inévitablement à une confusion des services. Sans
gouvernance, les projets SOA deviennent périlleux. En effet, la gouvernance
est essentielle pour identifier avec minutie les détails du concept et ses
méthodes de mise en œuvre. Ce chapitre constitue une introduction aux
concepts de gouvernance d’entreprise et d’architecture d’entreprise, qui sont
les deux éléments clé pour réussir la mise en œuvre de la SOA.
4.2 Pourquoi la gouvernance est-elle essentielle ?
Une première question s’impose : pourquoi la gouvernance est-elle vitale
dans la mise en œuvre de la SOA ? Pourquoi le besoin de gouvernance
devient-il aussi impérieux ?
Les opportunités de réutilisation des services sont cruciales pour la gouvernance SOA. L’un des objectifs de la SOA est de réduire les coûts par la réutilisation des services. L’expérience du monde orienté objet (OO world) et du
monde du développement basé composant (CBD world) montre qu’il n’est pas
facile de réutiliser des objets et des composants. La réutilisation ne coule pas
de source. Elle doit être planifiée et gérée avec minutie. Malgré les meilleures
intentions, les projets sont largement responsables de la façon, certes assez
autonome, dont les fonctionnalités sont fournies. Il est souvent beaucoup plus
aisé de développer des composants en partant de zéro que de rechercher les
propriétaires des composants réutilisables (si les propriétaires sont effectivement connus), puis de solliciter la réutilisation de ces composants et d’ap-
61
SOA for Profit
porter enfin les modifications requises. Nous devons désormais tirer les leçons
des expériences orientées objet et du développement basé composant, et nous
assurer que la réutilisation des services constitue une réelle réussite. Pour
cela, stratégies et gestion s’imposent.
Une conception de services adaptée constitue un autre facteur essentiel pour
la gouvernance SOA. Il en va de même du développement des processus
métiers. Dans la pratique, la conception des processus métiers et celle des
services vont de pair. Des méthodes sont indispensables pour garantir la mise
en place de services et de processus de manière standard.
Un autre élément moteur à prendre en compte est la gestion de la complexité.
Dans le passé, la mauvaise gestion des investissements informatiques a
entraîné une prolifération d’applications, de logiciels et de matériels. L’environnement informatique est devenu de plus en plus complexe, toute modification entraînant une perte de temps et d’argent.
La mise en œuvre de la SOA a une double finalité : elle aide à réduire la complexité liée à l’héritage et accroît flexibilité et opérabilité ; mais elle est intrinsèquement complexe car les grands groupes de fonctionnalités (applications)
doivent laisser la place à un nombre accru de petits groupes de fonctionnalités (services). Si la gestion de centaines d’applications apparaît déjà comme
une tâche considérable, l’ajout de centaines de services entraînera sans aucun
doute un sentiment de débordement.
Le nombre de services requis pour une entreprise qui possède déjà plus d’un
millier d’applications, est difficile à déterminer : en faut-il des centaines, des
milliers ? Tout dépend de l’étendue du déploiement des services. Une chose
est sûre : si nous créons et gérons des services de la même manière que nous
avons jusqu’ici géré les applications, la complexité va s’accroître de manière
exponentielle. Procédures et management sont vitales pour prévenir une telle
situation.
Le quatrième et dernier élément moteur est la question des investissements
et du financement. La SOA nécessite des investissements en matière d’infrastructures et d’expertise. Le problème est que les coûts élevés de démarrage
vont pénaliser le premier projet SOA et que cela aura un impact majeur négatif sur le business case concerné. De plus, la courbe d’apprentissage des premiers projets SOA sera plus abrupte, ce qui aura pour effet d’augmenter les
coûts et la durée du projet par rapport aux projets suivants qui bénéficieront
62
4 Gouvernance ou chaos
de l’effet de répétition. Il est donc essentiel d’appréhender les investissements SOA et les projets d’infrastructure non pas de manière isolée, mais
plutôt dans leur globalité. Les investissements doivent être gérés en portefeuilles. Il en découle logiquement la nécessité de mise en place de procédures, de principes et d’une politique de gestion, qui permettront en outre de
juger de la bonne adaptation du portefeuille.
De manière plus générale, nous pouvons affirmer que la gouvernance représente un prérequis indispensable pour exploiter tout le potentiel de la SOA.
Flexibilité d’action et réduction des coûts ne viennent pas naturellement ; ils
sont le fruit d’une démarche réfléchie.
La gouvernance SOA est indispensable au même titre que la gouvernance
des systèmes informatiques. Les éléments moteurs mentionnés (réduction
des coûts, accroissement de flexibilité et visualisation des investissements
en portefeuille) ne sont pas des nouveautés. Ils étaient déjà présents lorsque
le concept de gouvernance informatique est apparu. Il est désormais essentiel de garantir l’adoption proactive du concept de gouvernance SOA avant
que cela ne devienne un problème comme avec la gouvernance informatique.
Les deux figures ci-après montrent la différence entre une approche SOA
avec gouvernance et une approche SOA sans gouvernance [Weblayers
2005b].
Déploiement
AQ
Déploiement
Politiques de développement
Actions
Nouveaux processus métiers
Initiative 2
Initiative ...
Service
Gouvernance
Infrastructure SOA
Conformité
Initiative 1
Politiques d'action
Applications
Figure 4.1 : SOA avec gouvernance
63
SOA for Profit
La Figure 4.1 démontre qu’il existe un ensemble de services (cercles grisés)
indépendants des applications qui proposent ces services aux processus
métiers. La gouvernance mise en place à cet effet s’articule autour de politiques
de développement et d’actions ; elle englobe aussi la surveillance et le suivi de
leur conformité. Ces politiques sont également dites « principes architecturaux » et font partie intégrante de l’architecture d’entreprise de la société.
Développement
AQ
Déploiement
Actions
Aucune politique de développement
Nouveaux processus métiers
Aucune conformité
Initiative 1
Initiative 2
Initiative ...
Service
Gouvernance
Infrastructure SOA
Aucune politique d'action
Applications
Figure 4.2 : SOA sans gouvernance
Sans gouvernance, sans stratégie ni conformité, l’entreprise peut souffrir de
la création des services orientés applications et donc n’offrir quasiment que
des opportunités de réutilisation faibles, voire nulles. Par ailleurs, les services
sont développés de toutes les manières possibles, ce qui aboutit finalement à
une architecture informatique complexe, onéreuse et très inefficace.
La Figure 4.3 met en évidence la nécessité d’une gouvernance et d’une architecture d’un point de vue historique.
Système d’information
centralisé physiquement
- Compliqué,
mais complexité
maîtrisée
-
Système d’information
décentralisé
physiquement
Système d’information
découplé physiquement
mais intégré logiquement
Complexité non maîtrisée
Incohérence
Aucune pertinence
Découplage, aucune
intégration
-
Complexité maîtrisée
Cohérence
Pertinence
Découplage, mais
intégration
Figure 4.3 : Comment faire évoluer la complexité informatique
64
4 Gouvernance ou chaos
Au cours des années 1970 et 1980, les systèmes d’information étaient physiquement centralisés, ce qui permettait d’en surveiller la complexité. Dès les
années 1990, ces systèmes ont connu une décentralisation croissante, en partie due à l’émergence de la technologie client/serveur. Cette évolution a finalement abouti à une complexité grandissante qui n’a pu être endiguée.
Aujourd’hui, de nombreuses entreprises possèdent donc un système d’information décentralisé physiquement. Cette décentralisation est la cause de
nombreux problèmes d’intégration car les procédés et les systèmes ne sont
pas pertinents et cohérents et leur complexité s’est accrue au fil du temps.
Pour arriver à des activités et à un environnement informatique intégré, il est
crucial de disposer de compétences dans les domaines de la gouvernance et
de l’architecture. C’est la seule façon de parvenir à un stade où des composants physiquement séparés pourront fonctionner logiquement en interaction, de manière optimale et avec une complexité maîtrisable.
En conclusion, citons Gartner [Gartner 2006d], qui décrit les trois situations
possibles sans gouvernance SOA :
•
SOA brute
Dans ce cas de figure, les services sont mis en place de manière brute sans
aucune coordination. Personne ne connaît le nombre de services créés,
leur localisation et les possibilités de (ré-)utilisation. Une fonction
d’encadrement, en mesure d’assurer la coordination, est absolument
nécessaire. Des règles de gestion de la coordination doivent être définies
pour la création et l’adaptation des services.
•
SOA redondante
Cette situation est un peu mieux canalisée que la SOA brute. Néanmoins,
il existe un trop grand nombre de services qui recoupent en partie ou en
totalité les fonctionnalités d’autres services. Aucune opportunité de réutilisation des services n’est évidemment offerte. Dans ce cas, il existe peutêtre des règles qui régissent la création et l’adaptation des services, mais
aucun système pour faciliter leur réutilisation. D’où les nombreux services
redondants.
•
SOA achetée
Une infrastructure SOA existe mais n’est guère utilisée. Ici, on observe une
faible implication de la part des business units et aucun engagement dans
l’utilisation des services. La solution est donc un plus grand engagement
au sein de l’entreprise avec une identification claire des responsables de
la mise en œuvre de la SOA.
65
SOA for Profit
Le bilan est clair. Sans politique de gouvernance efficace, tous les avantages
liés à l’approche SOA seront inaccessibles. Par ailleurs, il est inimaginable
d’arriver à une architecture informatique moins satisfaisante que l’architecture de départ en dépit de tous les investissements : moins grande flexibilité,
niveau de réutilisation plus faible, et kyrielle inextricable de services dont
personne ne connaît le fonctionnement.
4.3 Qu’est-ce que la gouvernance SOA ?
Qu’entend-on exactement par « gouvernance SOA » et dans quelle mesure ce
concept est-il lié à d’autres formes de gouvernance ? Commençons par la
forme la plus élevée de gouvernance au sein d’une organisation, à savoir la
gouvernance d’entreprise.
La gouvernance d’entreprise est la capacité organisationnelle à exercer une
autorité d’encadrement permanente pour le développement de la stratégie
d’une entreprise, et pour la création, la mise en œuvre et le fonctionnement
ultérieurs de l’entreprise [Hoogervorst 2007].
Gouvernance d'entreprise
Gouvernance
informatique
Gouvernance
Entrée
Offre de produits et services
de l’entreprise
Produits et services
informatiques
Sortie
Figure 4.4 : Rapports entre gouvernance d’entreprise,
gouvernance informatique et gouvernance SOA
Le principal objectif de la gouvernance d’entreprise est de s’assurer que la
stratégie de l’entreprise est effectivement bien appliquée. De nombreuses
initiatives échouent. D’après Kaplan et Norton : « Diverses études indiquent
que 70 à 90 % des entreprises n’ont pas réussi à évoluer en s’appuyant sur
leurs stratégies ». Cet échec est imputable pour l’essentiel à un manque de
pertinence et de cohérence dans la mise en œuvre de la stratégie. Le but de
la gouvernance d’entreprise est précisément de veiller à ce que les initiatives
aboutissent à des mesures pertinentes et cohérentes. L’architecture d’entreprise est l’outil idéal pour garantir cette pertinence et cette cohérence.
66
4 Gouvernance ou chaos
La Figure 4.4 illustre les rapports entre la gouvernance d’entreprise, gouvernance informatique et gouvernance SOA. La gouvernance d’entreprise
concerne l’encadrement des produits et des services proposés par l’entreprise
à l’extérieur. La gouvernance informatique fait partie intégrante de la gouvernance d’entreprise, en se limitant néanmoins au suivi des produits et des
services informatiques.
La gouvernance SOA ne concerne pas seulement l’informatique ; elle s’applique également au niveau de l’entreprise. La Figure 4.5 illustre les sous-domaines de gouvernance influencés par l’introduction de la SOA.
Principaux domaines de gouvernance d’entreprise
- Stratégie d’entreprise, domaines concernés
- Architecture d’entreprise
- Création d’entreprise
- Analyse et modélisation des processus métiers
- Définition des exigences des performances métiers
- Analyse des informations
- Définition et certification des services
- Définition des exigences de support services
- Définition et adaptation de l’enregistrement des services
- Gestion des cycles de vie des services
- Gestion des portefeuilles de services
- Gestion des portefeuilles de projets
- Gestion des programmes d’entreprise
Principaux domaines de gouvernance
- Investissement et financement
informatique
- Souscription de contrats
- Stratégie informatique, précisions technologiques
- Architecture informatique (SOA par ex.) et
conception de haut niveau
- Infrastructures et services d’équipements
informatiques
- Gestion du cycle de vie informatique
- Encadrement de la gestion opérationnelle des
systèmes informatiques
- Gestion des portefeuilles de projets informatiques
- Gestion des programmes informatiques
Figure 4.5 : Domaines de gouvernance influencés par la SOA
Les domaines mentionnés sur la Figure 4.5 ne sont pas seulement importants
pour la mise en œuvre de la SOA ; ils sont essentiels pour la réalisation des
objectifs d’une entreprise de façon cohérente. La mise en œuvre de la SOA
est beaucoup plus simple au sein d’une entreprise où la gouvernance fonctionne correctement, et qui a intégré des mécanismes pour la gestion des
portefeuilles par exemple, ou pour les décisions d’investissements.
67
SOA for Profit
Nous ne considérons pas la gouvernance SOA comme une forme de gouvernance à part entière. En effet, pour la mise en œuvre de la SOA, il faut que
l’entreprise dispose déjà d’une politique appropriée de gouvernance d’entreprise et informatique et qu’elle laisse la place à l’introduction de services
basés sur de nouveaux concepts de gouvernance, comme la gestion du cycle
de vie des services et des portefeuilles de services.
Enfin, nous expliquerons la différence entre gouvernance et gestion. La gouvernance se rapporte à l’organisation des processus d’encadrement, alors que
la gestion concerne l’application des processus d’encadrement qui font appel
à des mécanismes et des structures de gouvernance.
Les sections ci-après apportent une description plus détaillée d’un certain
nombre de concepts spécifiques à la gouvernance SOA à savoir :
•
La gestion des portefeuilles de services
•
La gestion de cycles de vie des services
•
Le registre des services
4.4 La gestion des portefeuilles de services
L’un des principaux thèmes de la gouvernance informatique est le portefeuille
de services. Dans sa forme la plus rudimentaire, il s’agit d’une liste de données
sur les coûts, les bénéfices, les risques et la cohérence entre les changements
souhaités, les projets en cours ainsi que la gestion et l’adaptation régulières
des applications et des infrastructures.
Développement
Actions
Portefeuilles
de
projets
Portefeuilles
d’applications/
infrastructures
Figure 4.6 : Portefeuilles de gouvernance
Le portefeuille informatique se compose de deux parties. L’une, dédiée au
changement, est le portefeuille de projets; l’autre, consacrée au maintien en
condition opérationnelle, est le portefeuille d’applications et d’infrastructures. Ces deux portefeuilles demandent à être gérés. Cela signifie qu’un projet
ne doit pas simplement être évalué à l’aune de ses caractéristiques propres,
mais aussi de son interopérabilité avec l’ensemble des projets. Après tout, il
68
4 Gouvernance ou chaos
peut arriver que deux projets, vus séparément, apportent une certaine valeur
ajoutée, tout en étant en conflit du point de vue des portefeuilles. Il en va de
même pour l’ensemble des applications et des infrastructures. En effet, celles-ci nécessitent une gestion des licences comme des portefeuilles afin
d’éviter les redondances. Ainsi, si l’on considère un portefeuille d’applications, l’idéal est de ne voir figurer qu’une seule application par bloc de fonctionnalité.
Comme vous pouvez le constater sur la Figure 4.7, la SOA ajoute un composant de gestion essentiel par rapport à la Figure 4.6 :
Développement
Actions
Portefeuilles
de
projets
Portefeuilles
de services/
applications/
infrastructures
Figure 4.7 : Portefeuilles de gouvernance agrémentés du portefeuille de services
Une application est un ensemble spécifique de logiciels qui attribuent directement certaines fonctionnalités d’un ordinateur à plusieurs tâches que l’utilisateur souhaite effectuer. Un service est une tâche autonome et identifiable
(pour l’activité) proposée par une application ou un composant applicatif. En
fait, la SOA introduit une autre couche, celle des services.
De la même manière qu’avec les applications et les infrastructures, il est
essentiel de gérer le cycle de vie des services comme un portefeuille. Les
décisions doivent être prises en ces termes :
•
Quels sont les services requis ?
•
Quels sont les services requis en priorité ?
•
Le service est-il conforme aux critères définis ?
•
Qui finance la création et la maintenance du service ?
•
Qui est propriétaire du service ?
Dans la pratique, tout est une question de gestion. La gouvernance SOA doit
empêcher le développement non maîtrisé de services au sein du portefeuille.
De plus, le portefeuille doit toujours contenir un ensemble pertinent et cohérent de services conformes aux exigences de l’entreprise, qui prenne en
compte la globalité du cycle de vie.
69
SOA for Profit
En fait, la gestion des services en portefeuille offre un avantage ; les portefeuilles d’applications et d’infrastructures sont moins importants dans la
relation de l’entreprise avec son service informatique. Si la fonctionnalité de
l’entreprise s’articule autour des services, il sera alors possible d’affecter des
coûts, des bénéfices, des risques et une cohérence à ces services, même s’ils
sont proposés par des applications propriétaires. Les services doivent fournir
la fonctionnalité définie par l’entreprise dans certaines conditions. Ces
conditions sont documentées dans les descriptifs de services qui constituent
la base des accords sur les budgets, les investissements et les contrats de
maintenance.
La question de savoir qui doit gérer le portefeuille de services est intéressante. Nous estimons que la responsabilité incombe à l’entreprise. Après tout,
un service est un composant de la fonctionnalité de l’entreprise qui est utilisé
dans un processus métiers. Il est tout à fait possible que l’entreprise délègue
cette responsabilité à son service informatique.
Les applications et les infrastructures ne disparaissent pas dès lors que sont
introduits des services. Leur gestion demeure une nécessité ; mais elle passe
simplement sous la responsabilité de la direction informatique et n’est donc
pas un point de négociation entre l’entreprise et sa DSI. L’avantage est que le
dialogue entre le service informatique et le reste de l’entreprise se clarifie et
se simplifie. En revanche, la gouvernance informatique n’est pas simplifiée
par l’introduction de la SOA. Voici donc une autre raison d’aborder la gouvernance SOA.
Développement
Actions
Portefeuilles
de projets
Portefeuilles
de services
Portefeuilles
d’applications/
infrastructures
Figure 4.8 : Le portefeuille de services : la pièce maîtresse
70
4 Gouvernance ou chaos
4.5 Gestion du cycle de vie des services
La gestion des cycles de vie des services est un domaine important dans le
concept de gouvernance. En fait, toute entreprise doit gérer le cycle de vie de
ses actifs. Cette pratique est communément admise pour les biens d’équipements comme les bâtiments et les machines. Néanmoins, en informatique, la
gestion des cycles de vie n’en est qu’à ses balbutiements. Elle pose un problème majeur dans le domaine notamment des applications. En effet, au fil
du temps, beaucoup d’applications ont été conçues au sein d’une multitude
d’entreprises, quelques-unes d’entre elles seulement ayant été supprimées.
Dans une certaine mesure, cela est dû au fait que les nouvelles applications
ont repris les fonctionnalités des anciennes, mais ce n’est pas toujours le cas.
Tant que le nombre des fonctionnalités requises est limité, l’application ne
peut pas être supprimée. La tâche sera plus aisée avec les services car ceuxci ne représentent qu’une part restreinte des fonctionnalités. Ainsi, on pourra
plus facilement déterminer si un service doit être supprimé ou non. En revanche, les services deviennent également problématiques car multi-utilisateurs.
Dans ce cas également, tant qu’un service est utilisé, il ne peut pas être supprimé.
La Figure 4.9 illustre le cycle de vie d’un service.
État
Planifié
Spécifié
En cours de développement
Provisionné
Accepté sur plan opérationnel
Certifié
Publié
Opérationnel
Opérationnel
Retiré
Activité
Identification
Portefeuille des services utilisés
Spécification
Cohérence et pertinence préservées
Financement/Approvisionnement/Planification
Développement
Acceptation par SI
Certification
Publication
Souscription
Suppression graduelle
Arrêt
Portefeuille des services obsolètes
Figure 4.9 : Cycle de vie d’un service
71
SOA for Profit
Le Tableau 4.1 décrit les différentes étapes d’un service.
État
Description
Planifié
Le service figure dans le planning. Il correspond à une volonté
d’introduction. Il est décrit de manière globale et affecté à un
domaine (domaine du système ou domaine d’activité).
Spécifié
Le service a fait l’objet d’une spécification formelle exhaustive
(logique, qualité de service et conditions). Voir la section suivante
de ce chapitre.
En cours de
développement
Le service est en cours de développement.
Provisionné
Le service est prêt à être certifié. Les développeurs ont réalisé la
conception, les tests et la documentation.
Accepté sur le
Le service a été validé par le département responsable.
plan opérationnel
Certifié
Le service est conforme aux critères de qualité : fonctionnalités,
performances, documentation (description du service) et
acceptabilité du fonctionnement. Cet état est déterminé
indépendamment des développeurs.
Publié
Le service est disponible. Il est désormais soumis à un suivi de
modifications, à des adaptations et une surveillance.
Opérationnel
Le service est effectivement utilisé dans l’environnement de
production. Il fait l’objet d’une surveillance (exécution et
utilisation), et les problèmes de production sont traités.
Obsolète
Le service n’est plus proposé aux nouveaux utilisateurs. Les utilisateurs
du moment sont orientés vers de nouvelles solutions le plus tôt possible.
Le caractère non liant de cette incitation dépend de la situation.
Retiré
Le service n’est plus proposé et peut être supprimé du registre.
Tableau 4.1 : Étapes du service dans son cycle de vie
Dès qu’un service est identifié, il doit être intégré dans le portefeuille des
services. Ce n’est qu’après avoir été effectivement supprimé qu’il sera retiré
du portefeuille.
La gestion du cycle de vie des services incombe à l’entreprise. L’argumentation
évoquée pour la gestion des portefeuilles des services est également valable
dans ce cas, à savoir qu’un service est une fonctionnalité d’entreprise qui fait
partie intégrante d’un processus métiers. Si, par exemple, un processus de
traitement de commande utilise un service de consultation de données client,
la propriété de ce service de consultation (qui est placée sous la responsabilité
de l’entreprise) pourra être cédée à un département marketing et vente.
72
4 Gouvernance ou chaos
4.6 Registre des services
Tous les services sont consignés dans un registre des services. Le descriptif
de chaque service doit y figurer. La Figure 4.10 illustre cette approche.
Descriptif du service
Logique du service
- Fonctionnalités prévues
en termes de sémantique
- Sémantique (vocabulaire)
- Syntaxe (comment activer
le service)
Qualité du service
- Qualité opérationnelle
- Conditions
opérationnelles
Conditions de l'offre
- Prix
- Support
- Aspects juridiques
Figure 4.10 : Description du service
Tout d’abord, vous trouvez la description du service, sa logique. Cette logique
décrit la fonctionnalité que le fournisseur doit proposer, avec des informations
sur le procédé d’activation du service par l’utilisateur.
Ensuite, la qualité du service y est abordée. Il s’agit des conditions opérationnelles dans lesquelles les services sont assurés par le fournisseur. Les exigences non fonctionnelles, comme la disponibilité, la fiabilité et la scalabilité,
en déterminent la qualité. Les limitations (comme le nombre maximum d’utilisateurs simultanés) doivent également y figurer.
Enfin, les conditions de livraison, comme le prix du service, les conditions à
remplir par le fournisseur pour garantir le paiement et les accords concernant
le support et la fiabilité, doivent être spécifiés.
En plus de la description, il est essentiel d’indiquer le nom du propriétaire du
service, du fournisseur et des utilisateurs.
S’il existe un registre central, toutes les conditions sont réunies pour offrir
des possibilités de réutilisation. En consultant le registre, les clients potentiels
peuvent s’informer sur les services disponibles, sur leurs conditions d’utilisation et sur les personnes à contacter pour y accéder. Ajoutons également
que le registre est essentiel pour la gestion du cycle de vie des services.
73
SOA for Profit
4.7 Architecture d’entreprise
La Figure 4.11 montre que l’architecture d’entreprise fait partie intégrante
de la gouvernance d’entreprise et qu’elle en constitue un élément majeur.
L’architecture d’entreprise est en effet une compétence indispensable dans
la mise en œuvre de la SOA. Les architectes d’entreprise doivent dépasser
les limites des entités et des silos informatiques et atteindre un niveau
optimal de services au niveau global de l’organisation. De plus, l’architecture d’entreprise propose les processus et les produits nécessaires à la mise
en place d’une stratégie organisationnelle. L’Architecture d’Entreprise
Dynamique de SOGETI [Berg 2006a] est un modèle extrêmement utile pour
la gestion de l’architecture au sein d’une organisation, et en particulier,
pour la mise en œuvre de la SOA. Comme nous l’avons déjà expliqué, la
SOA est un type d’architecture et il incombe à l’architecte d’entreprise d’en
discuter.
4.7.1 Un modèle d’architecture d’entreprise
L’architecture d’entreprise dynamique (DYA, Dynamic Enterprise Architecture) contient un modèle aisément applicable à des mises en œuvre de la SOA.
Il s’agit d’un « squelette » autour duquel peuvent s’articuler les mises en
œuvre de la SOA et qui permet de déterminer l’importance de la SOA pour
une entreprise, en répertoriant les moyens de la mettre en place ainsi que les
ressources requises.
Le noyau du modèle de DYA est basé sur quatre (sous-)processus qui couvrent l’intégralité du changement, de l’élaboration d’une stratégie à sa mise
en place :
•
Dialogue stratégique – Par ce dialogue, les objectifs de l’entreprise sont
définis et intégrés dans des propositions concrètes de projets par l’intermédiaire de business cases. Les objectifs sont débattus au cours d’un dialogue mené entre le service informatique et le reste de l’entreprise.
•
Services architecturaux – Processus au cours desquels l’architecture est
formulée, puis proposée en vue des phases de dialogue stratégique et de
Développement avec architecture.
•
Développement avec architecture – Processus où les objectifs d’entreprise
doivent être atteints dans les délais stipulés, suivant les qualités et les
coûts anticipés. Dans le processus DYA, la phase de développement avec
architecture constitue le standard.
74
4 Gouvernance ou chaos
•
Développement sans architecture – Choix délibéré dans certains cas, impliquant peut-être des pressions extrêmes de délai, qui consiste à s’éloigner
du cadre architectural.
Gouvernance
Développement
sans
architecture
Nouveaux
développements
Solutions métier
Développement
avec
architecture
Dialogue
stratégique
Services
architecturaux
Solutions
métier
Processus
DYA
Architecture dynamique
Architecture
métiers
Architecture
d'information
Architecture
technique
Figure 4.11 : Modèle de DYA
Dans ce modèle, les services architecturaux (c’est-à-dire le développement et
la maintenance de l’architecture) constituent clairement un processus de support. L’architecture n’est pas une finalité en soi, mais un outil de gestion des
changements formulés pendant le dialogue stratégique, puis concrétisés pendant la phase de développement avec (ou sans) architecture. Ces changements
sont modulés de façon à servir au mieux les objectifs de l’entreprise. Comme
le modèle de DYA permet une identification précise des facteurs traités dans
les pratiques architecturales, il a été adopté par de nombreuses organisations.
4.7.2 Utiliser la DYA pour la SOA
En termes de DYA, la décision d’adopter ou non la SOA est prise pendant la
phase de dialogue stratégique. L’architecte d’entreprise facilite ce dialogue
car il définit les principes et modèles requis pour atteindre les objectifs d’en-
75
SOA for Profit
treprise, tout en garantissant un degré de cohérence mutuelle. Les principes
et les modèles SOA font partie des outils standards à sa disposition. À lui
également de dresser la liste des avantages et des inconvénients de son
concept de SOA par rapport aux objectifs de l’entreprise. En dernier ressort,
c’est la direction qui doit statuer sur la mise en œuvre des objectifs et des
business cases associés. Le choix d’une SOA découle logiquement des objectifs
qu’une entreprise se fixe pour elle-même et non pas l’inverse. Il est donc
essentiel que l’entreprise dispose des compétences requises pour sonder toutes les opportunités de SOA et les exploiter dans les discussions sur les objectifs à atteindre.
Avec le modèle de DYA, vous pouvez bénéficier des avantages des services
avant que l’architecture ne soit terminée. Le processus de développement
sans architecture permet la mise en œuvre de services même en l’absence
de principes fondateurs. Dans ce cas naturellement, l’entreprise doit comprendre qu’un « cycle d’adaptation » s’impose pour tout intégrer dans l’architecture à réaliser. Comme les décisions stratégiques sur la SOA sont
prises lors du dialogue stratégique, il est possible d’établir une analogie
entre les exigences liées au projet (l’utilisation des services à l’instant T)
et les exigences organisationnelles (des investissements décalés dans le
temps pour que les services puissent s’intégrer dans une architecture de
plus grande envergure). Dans tous les cas de figure, vous devrez empêcher
toute croissance non maîtrisée des services hors des limites de l’architecture.
L’utilisation du modèle de DYA pour la SOA offre plusieurs avantages :
•
Avec ce modèle, la SOA n’est pas une finalité en soi mais devient un moyen
d’atteindre un objectif. La SOA est un type d’architecture qui peut servir
de déclic. Elle doit faire l’objet de discussions dans le cadre de la phase de
dialogue stratégique.
•
La SOA est mise en œuvre suivant le principe du « juste à temps, juste
assez » dicté par les objectifs organisationnels de l’entreprise. Chaque
objectif est un pion utilisable dans notre jeu SOA.
•
Gouvernance et architecture sont deux compétences essentielles requises
pour réussir les mises en œuvre de la SOA. Elles constituent les règles de
base à suivre pour réussir et assurer un suivi.
•
Vous avez également la possibilité de vous lancer dans un projet SOA sans
architecture, en sachant néanmoins que les services développés devront
être intégrés par la suite dans l’architecture.
76
4 Gouvernance ou chaos
Si une entreprise envisage de mettre en œuvre une SOA d’envergure à l’instar d’une transformation stratégique, elle devra préalablement mener un dialogue stratégique pour déterminer les objectifs à prendre en compte. Ensuite,
elle devra mettre en place une vision d’entreprise SOA dans le cadre de son
dialogue stratégique.
Si une entreprise aspire à une SOA plus modeste, avec un projet unique, il est
alors préférable de déterminer si elle doit ou non définir au préalable une
vision métier SOA. Sinon, il faudra au moins définir à quel stade cela deviendra indispensable. Le problème est que certains projets ne seront jamais
suspendus dans l’attente d’une vision SOA et qu’ils progresseront quelle que
soit la situation. Vous aurez donc besoin de vous appuyer au minimum sur les
concepts de gouvernance et d’architecture ; faute de quoi, la mise en œuvre
de la SOA entraînera inévitablement une complexité accrue avec les coûts de
maintenance associés.
Il est facile d’en tirer une conclusion. Que vous décidiez de partir pour un
petit ou un grand voyage SOA, la première étape sera toujours le dialogue
stratégique.
Outre la vision d’entreprise que vous définirez pendant le dialogue stratégique, vous devrez élaborer des business cases et des plans pour démarrer un
ou plusieurs projets SOA. À cette fin, vous pouvez ébaucher les éléments de
l’architecture en recourant à des méthodes spécifiques que vous combinerez
aux meilleures pratiques, comme les modèles industriels. Vous pouvez également utiliser des paramètres d’entrée (individu, informations, processus, réutilisation et connectivité) pour identifier les éléments déclencheurs et les
objectifs d’entreprise par rapport à des projets SOA spécifiques. Pour cela,
reportez-vous au chapitre 9. Par ailleurs, des sujets tels que la formation et la
recherche dans le domaine des outils peuvent être traités à ce stade. Comme
le démontre clairement le Modèle de Maturité SOA (que nous présenterons
au chapitre 8), la mise en œuvre a des répercussions multiples.
Une fois de plus, tous les choix sont conditionnés par les attentes de l’entreprise vis-à-vis de la SOA et par la méthode adoptée. Si une entreprise souhaite commencer prudemment en n’utilisant que quelques services Web, inutile de mettre en place des concepts de modélisation. Chaque chose en son
temps. En résumé, le dialogue stratégique conduit à des choix de ressources
nécessaires dans une situation donnée, avec la garantie que les décisions
d’investissements prises seront mûrement réfléchies.
77
SOA for Profit
4.7.3 Les différentes visions d’une architecture
Comment les différentes perspectives d’architecture d’entreprise s’apparentent-elles à la SOA ? Dans les services d’architecture, l’architecture est destinée à soutenir les étapes de dialogue stratégique et de développement. Il
existe trois types d’architectures : une architecture pour les décisions stratégiques, une architecture pour l’élaboration des business cases et, enfin, une
architecture qui constitue la trame nécessaire du projet [Berg 2006a]. Nous
étudierons ces trois types dans les sections qui suivent.
Une architecture pour les décisions stratégiques
En général, la première architecture citée (destinée à faciliter les prises de
décision stratégiques) a une fonction de coordination. Cette architecture doit
permettre d’identifier les fonctionnalités partagées, de positionner les développements individuels et d’introduire une cohérence mutuelle. Son objet est
de canaliser l’ensemble des changements et de garantir que les exigences
d’infrastructure seront remplies en temps utile. Cette forme d’architecture
relève d’un niveau conceptuel très élevé ; elle est de grande envergure et sert
de support aux directeurs dans leurs prises de décisions stratégiques. Elle est
souvent désignée par l’appellation plan d’urbanisme ou, en particulier dans
les grands groupes et les sociétés multinationales, par architecture d’entreprise. Dans le contexte SOA, le plan d’urbanisme doit identifier les domaines
où la SOA est susceptible d’apporter une valeur ajoutée. Une liste de principes
et de directives SOA applicables au niveau de l’entreprise doit également
figurer dans ce plan. Les directives peuvent aboutir à des projets ; mais il est
toutefois conseillé de les identifier au préalable, puis de les intégrer dans
l’architecture d’entreprise.
Une architecture pour les business cases
L’architecture destinée à assurer un soutien au niveau tactique pour des business cases concrets revêt une fonction de pilotage plus direct. Elle permet de
s’assurer que les changements spécifiques se déroulent effectivement comme
prévu. Sa portée est souvent plus limitée (par exemple à l’échelle d’une entité,
d’un domaine ou d’un programme d’activité) et plus précise dans le niveau de
détail. Elle est appelée architecture de domaine et peut porter un nom spécifique.
Lorsque vous avez décidé qu’un domaine sera basé sur un service, il est indispensable que l’architecture du domaine permette la mise en œuvre de la SOA
dans ce domaine précis. Pour ce faire, vous pouvez établir des modèles de la
future architecture en vous appuyant sur les services métiers que ce domaine
doit fournir. Ensuite, vous pourrez représenter ces services dans l’environne-
78
4 Gouvernance ou chaos
ment applicatif existant pour obtenir un aperçu des transformations que devra
subir le domaine en question. Outre les domaines fonctionnels, il existe des
domaines techniques comme l’intégration, la gestion des services et l’intelligence métier. Ces derniers décrivent les stratégies et les directives à suivre pour
appliquer certaines technologies ou, plus généralement, pour traiter un domaine
au regard de la technologie. Prenons le cas d’une entreprise qui souhaite mettre
en œuvre une SOA ; l’architecture peut être un domaine technique séparé pour
lequel des politiques et des directives seront définies en vue de l’établissement
d’un ensemble commun d’accords sur la mise en œuvre de la SOA. Dans l’architecture de référence SOA d’IBM [IBM SOA Reference Architecture], il existe
onze domaines distincts pour lesquels des choix s’imposent. [IBM 2005b].
Développement
Optimisation et innovation métiers
Interaction
Processus
Information
ESB
Partenaire
Application
métiers
Accès
Gestion des services informatiques
Utilisation d’une architecture de référence SOA
L’architecture de référence est un outil puissant dans la mise en œuvre de la SOA. De
manière générale, cette architecture couvre les principales fonctionnalités de l’architecture SOA. Sur la Figure 4.12, l’architecture de référence d’IBM est divisée en onze domaines, ce qui présente un certain nombre d’avantages majeurs. En effet, les entités peuvent déployer des ressources adaptées pour satisfaire les souhaits et les exigences
spécifiques aux domaines ; inutile donc d’être un expert dans tous les environnements.
Un usage rationnel des ressources est ainsi possible ; les coûts de formation sont
réduits, des ensembles d’outils adaptés peuvent être utilisés dans chaque domaine et
de nouvelles fonctionnalités être mises en œuvre de façon plus performante.
Infrastructure
Figure 4.12 : Architecture de référence SOA
Les principaux domaines de l’architecture de référence sont les suivants : Interaction,
Processus, Information, Partenaire, Application métiers et Accès. Ce sont les domaines du logiciel d’application.
79
SOA for Profit
Les autres composants de l’architecture de référence (innovation et optimisation
métier, développement, gestion des services informatiques et infrastructures) sont
des fonctions annexes aux premières. Ces fonctions sont utilisées pour l’élaboration
de modèles sur le processus de création de l’activité, pour la conception et l’assemblage de logiciels, la mise en œuvre d’applications et la gestion de l’environnement
métiers et informatique opérationnel.
Si vous examinez plus en détail les fonctions interaction, processus et information,
vous remarquerez qu’elles ressemblent beaucoup aux fonctions classiques de logique
présentation, logique métiers et logique données. Si l’on considère ensuite que la
fonction application métiers est une sous-fonction de processus, on reconnaîtra aisément une architecture système distribuée de type N-tier.
Nous ne voulons pas limiter l’utilisation des services d’une SOA particulière à la seule
logique. Tous les composants applicatifs, y compris la logique de présentation et la
logique données sont considérés comme des services. Nous allons maintenant dé­crire
brièvement chaque fonction.
Interaction
Cette fonction concerne la logique de présentation des composants de la création
d’activité qui favorise l’interaction entre les applications et les utilisateurs finaux. Ici,
l’interaction avec le monde extérieur ne se limite pas à la seule interaction humaine.
Il est également possible d’agir par une logique d’interaction avec les RFID et d’autres
équipements industriels, comme des capteurs et des véhicules. L’authentification et
l’autorisation font partie intégrante de ce bloc.
Processus
Cette fonction couvre différentes formes de la logique compositionnelle, dont, en
particulier, les flux de processus métiers et les machines d’état métiers (machines à
l’état fini pour la composition du métier). Nous considérons comme valables ces deux
types de mécanismes plus d’autres formes (comme les règles métiers ou le traitement
de l’arborescence des décisions) ainsi que d’autres modèles mieux adaptés pour
définir la composition du service.
Application métiers
Cette fonction s’applique aux services exécutables nécessaires à l’intégration de nouveaux
composants applicatifs dans le système. Ces composants constituent la nouvelle logique
métiers à suivre pour adapter les processus métiers existants en fonction de l’évolution de
l’entreprise en matière de concurrence et de clientèle. De la création et de la mise en œuvre
des nouveaux composants de la logique métiers découlent de nouvelles opportunités de
réutilisation totale, les nouveaux composants entrant désormais dans la composition de
80
4 Gouvernance ou chaos
processus métiers novateurs ou adaptés au fil du temps. L’application métiers intègre des
fonctionnalités essentielles qui permettent au programmeur traditionnel de créer des composants logiques modulables, flexibles et réutilisables.
Informations
Cette fonction concerne principalement la logique données sous-jacente à la création
d’une activité. Elle peut être perçue suivant deux angles différents. Vue d’en haut, la
fonction offre un accès à l’environnement des données clé d’une entreprise. Ces
services de données sont accessibles aux applications métiers comme les services.
Les applications possibles sont, par exemple, la gestion des données clé, l’intelligence
métiers, la gestion des contenus, l’intégration des informations, la gestion des données. Vue d’en bas, la fonction informations possède sa propre architecture pour la
gestion des flux de données au sein de l’entreprise.
Accès
La fonction Accès assure l’intégration de l’application patrimoniale existante au sein
d’une SOA. La fonctionnalité existante étant assurée, elle est par conséquent réutili­
sable comme un service. Dans ce processus, il y a lieu de vérifier si la fonctionnalité
actuelle (propriétaire) s’intègre toujours dans la sémantique du business model dans
lequel elle doit figurer.
Partenaire
Cette fonction est comparable à la fonction interaction, mais elle est plus spécifiquement orientée vers la fourniture de services à des partenaires, y compris vers le
contrôle de l’interaction avec un partenaire tiers. D’un autre point de vue, les deux
fonctions Partenaires et Accès sont comparables dans tous les cas où des services
spécifiques sont fournis par un partenaire choisi. On peut penser ici à un service
externe, comme les calculs d’intérêts des processus métiers, qui pourrait constituer
un élément à part entière en plus de ses « propres » services.
Bus de services d’entreprise
Le bus de services d’entreprise (ESB) est un composant majeur dans l’architecture de
référence SOA. Le bus a plusieurs fonctions comme l’acheminement des messages,
la traduction des formats de messages disponibles et la conversion des protocoles de
transfert. Il est ainsi possible d’activer un service via l’ESB sans connaître le langage
dans lequel ce service sera assuré ni où ce service fonctionne. De même, l’ESB assure
l’interface entre l’utilisateur et le fournisseur de services. Sa présence au sein de
l’architecture de référence SOA est transparente par rapport aux autres fonctionnalités présentes au sein du domaine applicatif.
81
SOA for Profit
L’ESB joue un rôle si important dans l’environnement SOA qu’il semble impossible
d’envisager une SOA sans lui. Mais il n’en est pas ainsi. Inversement, certains peuvent
croire qu’avec un ESB, vous possédez automatiquement une SOA. Cela n’est pas vrai
non plus. Les deux concepts sont apparentés et, si les circonstances le permettent, se
renforcent mutuellement. En revanche, ils ne sont pas inextricablement liés.
Innovation et optimisation métier
Cette fonction peut servir à analyser les performances métier et, le cas échéant, à
adapter le processus de création d’activité. Fréquemment, on utilise un ensemble
d’outils pour simuler les effets de certains changements sur l’activité concernée. Vous
pouvez également utiliser les résultats pour apporter des modifications à ce niveau.
De même, vous avez la possibilité de définir des indicateurs clé de performances (KPI).
Ces KPI peuvent être rattachés à l’environnement système du domaine de gestion du
service informatique pour permettre un contrôle rapide ou leur activation. Vous obtenez ainsi de nouveaux paramètres d’entrée destinés à d’éventuels changements dans
le processus de création d’activité.
Développement
Cette fonction est l’élément essentiel de toute architecture d’intégration exhaustive.
L’architecture SOA comporte d’une part, des outils de développement dédiés au
paramétrage pour encourager les opportunités d’infrastructure et d’autre part, des
outils de gestion des performances métiers utilisés pour le suivi et la gestion des mises
en œuvre exécutables à la fois au niveau des systèmes informatiques et des processus
métiers.
Gestion des services informatiques
De nos jours, la plupart des entreprises ont recours à un processus normalisé pour
assurer la gestion et le contrôle de leur environnement informatique. Le processus le
plus connu, ITIL (Information Technology Infrastructure Library), a été conçu comme
un modèle de référence à utiliser pour la mise en place des systèmes informatiques.
Le recours à un contrat de niveau de service (SLA) qui garantit la qualité des accords
entre le client et le fournisseur de services, est primordial. Le SLA est un contrat conclu
entre l’utilisateur et le fournisseur des services dans lequel sont spécifiés le niveau de
qualité, les parties impliquées et les conditions d’exécution des services.
Infrastructure
Dans ce modèle de référence, l’infrastructure est ce que nous appelons « traditionnellement » l’infrastructure, à savoir les équipements, les systèmes d’exploitation, les
82
4 Gouvernance ou chaos
unités de stockage entre autres. Comme nous l’avons observé en présentant les
concepts simples du chapitre 3, avec la SOA, une multitude de services peuvent être
apparentés à une infrastructure, mais ce n’est pas notre propos ici.
Dans la pratique, la SOA est principalement centrée sur l’architecture métier et information. Elle aide à optimiser la flexibilité des processus d’entreprise. Néanmoins,
cette flexibilité n’est possible que s’il existe une structure sous-jacente pour assurer
une interface continue avec les exigences propres à un environnement SOA. En
d’autres termes, la flexibilité de l’entreprise est intimement liée à la flexibilité de l’infrastructure informatique.
De façon générale, un environnement applicatif classique se compose d’applications
verticales (monolithiques) supportées par une infrastructure pilotée par des applications. Les diverses ressources informatiques (serveurs et bases de données par exemple) sont directement rattachées à cet environnement dans lequel toute capacité
inexploitée ne peut être affectée à d’autres applications proches. D’où le coût élevé
des actions et la complexité des changements.
L’idéal serait une infrastructure orientée services entièrement constituée de services
d’infrastructure avec une couche de communication autorégulatrice, flexible et
standardisée, qui peut supporter la transformation d’une infrastructure verticale
pilotée par des applications en une infrastructure plus horizontale basée sur les
services.
Une architecture qui constitue la trame de vos projets
Enfin, l’architecture qui constitue la trame d’un projet spécifique, est plus
directement concernée par le niveau opérationnel. Dès lors qu’un business
case positif devient un projet, une architecture est nécessaire pour définir la
trame sur laquelle se baser pour les décisions de création. L’accent est mis
sur le processus de création, c’est-à-dire sur les directives et les standards
auxquels le projet doit être conforme, et aussi sur la délinéarisation des projets et de toutes questions concernant les opportunités de réutilisation. Ces
architectures fournissent le niveau de détail requis par le chef de projet pour
disposer d’une base sur laquelle il s’appuiera pour prendre les décisions
propres à un projet particulier. Ce type d’architecture constitue l’architecture
de démarrage projet (PSA, Project-Start Architecture). Tout projet doit être
basé sur une PSA qui prescrit les services à réutiliser et les services à développer ou adapter. La PSA englobe aussi les contrats de niveau de service
applicables au projet.
83
SOA for Profit
Naturellement, ces architectures ne coexistent pas indépendamment les unes
des autres. En fait, il existe plusieurs façons de voir un même objectif, suivant
des perspectives différentes dans des circonstances identiques pour des finalités et des groupes cibles divers.
Nouveaux
développements
Développement
avec
architecture
Dialogue
stratégique
Plan
d'urbanisme
Architecture
domaine
Solutions
métier
Architecture
démarrage
projet
Services
architecturaux
Figure 4.13 : Différentes perspectives d’architecture
Il est essentiel d’être conscient des différences de perspective. Si vous êtes
sensible à la perception des autres, vous aurez plus de chances d’obtenir une
architecture pratique et bien perçue par les personnes qui ne l’ont pas définie.
Évitez l’erreur d’aller trop en profondeur et le danger de vous perdre dans
des détails qui ne correspondent pas à la finalité de l’architecture.
Enfin, n’oubliez pas que plus votre architecture d’entreprise et vos compétences de gouvernance seront réfléchies, plus l’adoption et la mise en œuvre
de la SOA seront aisées. Enrichir votre concept d’architecture d’entreprise
avec DYA vous donnera de gros avantages.
4.8 Comment déployer la gouvernance SOA
Une entreprise qui gère son concept de gouvernance d’entreprise et d’informatique a plus de chance de réussir dans la mise en œuvre de sa SOA qu’une
entreprise dans laquelle ces types de gouvernance n’en sont qu’au tout début.
Définir une méthode de gouvernance SOA consiste à adapter et à enrichir les
mécanismes existants.
84
4 Gouvernance ou chaos
La SOA peut également jouer le rôle d’élément catalyseur pour la gouvernance d’entreprise et informatique. Étant donné que la gouvernance SOA est
cruciale dans la réussite de la mise en œuvre, elle peut participer au développement et à l’amélioration des concepts.
Que faire pour planifier la gouvernance ? Voici les trois domaines d’intérêt :
1. Attribution des rôles et des responsabilités.
2. Mise en place d’un mécanisme de gestion.
. Définition des stratégies.
Dans les sections qui suivent, nous allons étudier ces domaines plus en détail.
Toutefois, sachez que le principe de base dans le déploiement de la gouvernance SOA est de rester aussi simple que possible.
Rôles et responsabilités
L’attribution des rôles et responsabilités permet de connaître les responsabilités
de chacun. Pour connaître les décisions à prendre, il est essentiel d’être clair et
précis par rapport aux procédés de gouvernance. Ensuite, vous pourrez déterminer les personnes qui possèdent le pouvoir de décision dans ces procédés en
utilisant des techniques comme RACI, RAEW. Un exemple de gouvernance SOA
peut être la refonte des services, puis l’attribution du pouvoir à une seule personne ou un seul groupe de personnes pour valider la création d’un service.
RACI et RAEW : explication
Les lettres RACI signifient :
• (R) Responsible (Responsable) : propriétaire du projet/problème.
• (A)Accountable (Décideur) : personne détenant l’autorité finale et validant les
éléments à fournir.
• (C)Consulted (Consulté) : personne possédant les informations et/ou le potentiel
pour terminer le travail.
• (I)Informed (Informé) : personnes informées mais non nécessairement consultées.
Les lettres RAEW signifient :
• (R)Responsibility (Responsabilité) : personne en charge de la fourniture des éléments.
• (A) Authority (Autorité) : personne contrôlant et validant les éléments à fournir.
• (E)Expertise (Expertise) : personnes donnant des conseils en se fondant sur une
certaine expertise.
• (W)Work (Travail) : personnes participant à la mise en place des éléments à fournir.
85
SOA for Profit
Le Tableau 4.2 (cf. p. 88) est un outil pratique pour déterminer les rôles et les
responsabilités dans la mise en œuvre de la SOA. La définition des rôles et
responsabilités est une étape décisive dans le concept de gouvernance SOA.
En indiquant dans le tableau les noms des représentants de toutes les fonctions impliquées dans la SOA, vous obtiendrez une vue d’ensemble utile de
« qui fait quoi » et des décideurs ultimes.
Les tâches énumérées dans le tableau sont associées aux diverses étapes du
cycle de vie d’un service.
Les mécanismes de gestion
Les mécanismes de contrôle sont des modèles utilisés dans le processus de
décision. Il peut s’agir d’un groupe de personnes chargé de prendre des décisions spécifiques, mais aussi d’une méthode de rétrofacturation ou la création
d’un marché de services. La désignation d’une autorité responsable du suivi
des étapes de création et d’utilisation des services est un exemple de mécanisme de gestion de la gouvernance SOA. Cette autorité est en droit de refuser la création du service.
Un autre exemple de mécanisme est le contrat de niveau de service (SLA) qui
spécifie les conditions de fourniture du service.
Gouvernance informatique et mécanismes de contrôle
De nombreux mécanismes communs de contrôle de la gouvernance informatique,
comme les équipes de conseil informatique et processus métiers, sont décrits dans
l’ouvrage de Broadbant et Weil [Broadbent 2002]. Dans plusieurs publications de
suivi de Gartner [Gartner 2006e], ces mécanismes sont appliqués à des projets de
SOA. On obtient ainsi l’organisation suivante :
Comité exécutif : renforce les canaux décisionnels et prend les décisions de financement. Dans la SOA, ce comité peut servir de comité directeur « suprême » qui statue
sur les problèmes que le Conseil SOA (cf. paragraphe suivant) ne peut résoudre.
Conseil informatique de l’entreprise et responsables informatiques : étudie les financements et oriente l’engagement des responsables des processus métiers. Lorsqu’il se
réunit en formation de Conseil SOA, c’est l’instance où les décisions majeures de gouvernance SOA (par exemple, « est-ce réellement un service nouveau et réutilisable ? »)
sont débattues et, dans certains cas, prises en principe par un comité restreint de participants. Si aucun accord ne peut être conclu, le Conseil délègue les questions au comité
de pilotage SOA.
86
4 Gouvernance ou chaos
Comité de leadership informatique : assiste les pratiques de travail collaboratives
entre plusieurs départements informatiques. Dans la SOA, il est essentiel d’encourager les initiatives des développeurs et de promouvoir les nouvelles méthodes
d’évaluation (c’est-à-dire sur la réutilisation des services existants et le développement des services réutilisables, et non pas uniquement le développement de nouveaux services).
Comité d’architecture d’entreprise : noyau du Centre de compétences d’intégration
(ICC, Integration Competence Centre) et centre décisionnel majeur de la SOA.
Responsables des relations métier/informatique : fonction fondamentale pour
garantir l’engagement des responsables des processus métiers et valoriser les accords
sur les services réutilisables, de haute granularité.
Équipes processus avec membres informatiques : très souvent partie intégrante
de l’ICC, même avant toute discussion sur la SOA. Parfois, ces équipes constituent
un centre d’excellence si des pratiques de gestion des processus métiers bien ancrées
existent déjà. Leur travail consiste à façonner la SOA, en particulier lorsqu’elle est
définie du haut vers le bas, en commençant par les processus métiers (ce qui est
courant dans certaines industries verticales, comme l’assurance).
Contrats de niveau de service : leur objet varie de la qualité technique des exigences
sur les temps de réactivité du service au temps de développement de services réutilisables, de plus haut niveau pour les propriétaires de processus métiers. À utiliser sans
restriction.
Arrangements de rétrofacturation : généralement utiles pour façonner le comportement et pour compenser des coûts. Couramment utilisés dans la SOA afin de
répartir les coûts de maintenance des services réutilisables entre plusieurs propriétaires d’application, en fonction de l’usage évalué du service par les diverses applications.
87
SOA for Profit
Tâches
Fonction
Identification
Analyse globale du processus
Responsable
Décideur
Analyse globale des
informations
Formulation d’un descriptif
global du service
Détermination des domaines
métiers
Contact avec des métiers
(externes) utilisant les services
Tenue des registres de service
Spécification
Analyse détaillée du
processus
Traitement des critères de
performance
Analyse détaillée des
informations
Formulation d’un descriptif
détaillé des services
Tenue d’un registre des
services
Financement
Financement
ApprovisionneApprovisionnement/
ment/Planification Planification
Développement
Développement des systèmes
orientés services
Tenue du registre des services
Certification
Certification
Tenue du registre des services
Publication
Tenue du registre des services
Contrats
Contact avec des entreprises
(externes) utilisant les services
Tenue du registre des services
Retrait progressif
Analyse des processus
Analyse des informations
Tenue du registre des services
Suppression
Tenue du registre des services
Tableau 4.2 : Outil de définition des rôles et des responsabilités
par rapport au cycle de vie des services
88
Consulté
Informé
4 Gouvernance ou chaos
Stratégies
Les stratégies sont destinées à éviter une croissance non maîtrisée et à garantir des pratiques de travail efficaces (comme la réutilisation de solutions
apportées à des problèmes récurrents). Elles restreignent la liberté de création et définissent des limites. Néanmoins, en disposant de limites plus claires,
d’autres possibilités se profilent. Les stratégies transparaissent dans les principes, les directives, les standards et les consignes. Elles font partie intégrante
de l’architecture d’entreprise. Un ensemble d’instructions pour la création
d’un service constitue un exemple de politique de gouvernance SOA.
Il ressort clairement des exemples qu’une activité n’est pas réalisable sans
l’autre. Il n’est pas très judicieux de mettre en place des stratégies sans
attribuer de mécanismes de gestion car, en général, les individus ne se soumettent pas aux stratégies. De même, il n’est pas non plus très utile de
définir des mécanismes de gestion sans attribuer de pouvoirs ; en effet, dans
ce cas, vous risquez de n’obtenir que des groupes de discussions sans mission précise.
Rôles et
responsabilités
Mécanismes
Stratégies
Figure 4.14 : Les trois composantes de la gouvernance
La mise en place d’un mécanisme de contrôle et l’attribution de pouvoirs sont
principalement liées à la fonction d’encadrement, la véritable gouvernance.
Quant à la définition des stratégies, elle relève de l’architecture d’entreprise.
En fait, gouvernance d’entreprise et architecture d’entreprise sont les deux
faces d’une même pièce ; ces deux concepts sont interdépendants. La gouvernance d’entreprise sans architecture d’entreprise aboutit certes à des mécanismes de gestion, mais sans contenu à gérer. Pour sa part, l’architecture
d’entreprise sans gouvernance offre un contenu de gestion mais sans aucune
directive pour la guider.
89
SOA for Profit
Les structures organisationnelles de la gouvernance
L’une des méthodes permettant d’organiser les différents éléments d’une SOA consiste à
recourir à une structure organisationnelle transversale, constituée des entités suivantes :
Conseil d’architecture de transformation métiers SOA
Cette équipe est chargée de collecter les exigences liées à l’activité, d’effectuer une
analyse du domaine métiers et de l’ingénierie métiers tout en identifiant les composants, services et modules de processus nécessaires. Au lieu de suivre une approche
strictement descendante (top-down), le conseil doit nuancer sa stratégie en combinant des méthodes du haut vers le bas, des méthodes ascendante (bottom-up) et des
méthodes basées sur les objectifs pour identifier correctement les services. L’équipe
doit notamment s’assurer que la granularité exposée des services définis est conforme
aux exigences et spécifications métiers, en assurant la corrélation des composants
métiers et des composants informatiques en tant que services.
Comité d’architecture technique SOA
Cette équipe assure l’alignement des métiers et des services informatiques en appliquant les normes du secteur et les standards de l’entreprise ; techniquement, elle
veille à ce que les services exposés soient conformes aux exigences d’évolution et de
réutilisabilité définies dans les directives générales pour le développement informatique de l’entreprise. Cette équipe est très informée des tendances émergentes au sein
du secteur, des technologies de pointes et des efforts de normalisation. Elle doit
encadrer les projets techniques de l’architecture d’entreprise (plan informatique directeur de l’entreprise), tout en identifiant les architectures de niche et en favorisant les
opportunités de réutilisabilité. Elle travaille en étroite collaboration avec l’équipe de
transformation SOA.
Centres de conception et développement des composants
Il s’agit des équipes d’informaticiens habituelles. Elles assurent la conception et le
développement des composants et des procédés et apportent de nouvelles compétences comme la modélisation des processus métiers. Cette équipe propose un projet
de solution, des abstractions conceptuelles de haut et de bas niveau, une analyse et
une conception orientée services ainsi que diverses phases de test comme les tests
unitaires, les tests d’intégration, les tests système et les tests de validation.
Centre d’opérations
Enfin, une équipe de production est chargée des différents aspects opérationnels des
composants des services, à savoir : la gestion de la qualité des services, la mise en
place d’accords d’entreprise et de contrats de niveau de service, la gestion de l’envi-
90
4 Gouvernance ou chaos
ronnement de sécurité, la rétrofacturation des services et l’assurance des recettes.
Elle est responsable du déploiement des services, des opérations de maintenance
habituelles et de la gestion générale du système.
Toutes ces entités doivent compter dans leur rang les personnes les mieux adaptées
aux nouveaux rôles définis dans une entreprise orientée services. Dans le chapitre 7
sur les individus orientés services, nous présenterons les nouveaux rôles ou les rôles
nouvellement (re)définis pour tirer le meilleur profit de la SOA.
Le Centre d’excellence SOA (COE, Center of Excellence) constitue une outil éprouvé
pour guider la gouvernance SOA au sein d’une entreprise. Ce centre se compose, de
préférence, de responsables reconnus et réputés dans les différentes disciplines illustrées à la Figure 4.15.
Garantir la visibilité des meilleures
pratiques d'évaluation SOA sur les
tableaux de bord métier et SI des
informations d'usage et de projet.
Tableaux métier et informatique
Garantir la primauté dans la vitalité
et la formulation de l’architecture. Évaluer
et affiner en continu une trame
architecturale et promouvoir les actifs en
vous basant sur les éléments internes et
externes.
Mener des études sur l'architecture SOA.
Procéder à des contrôles indépendants
concernant la création et l'architecture au
niveau des applications et de
l'infrastructure clé.
Gérer les modifications du cycle de vie
SOA. y compris les stratégies de
publication, d'utilisation et de suppression
de l'infrastructure des services pour
faciliter l'accès et vérifier la vitalité du
service.
Assurer les transferts de compétences et
visualiser les concepts de manière
anticipée. Identifier les décalages de
compétences et établir une cartographie
des développements. Piloter l'usage des
nouvelles technologies et techniques
(ex. : BPM).
Proposer une entité unique détentrice du
pouvoir décisionnel et communiquer les
meilleures pratiques, les actifs et les
modèles SOA.
Centre
d’excellence
Prévoir un plan pour le portefeuille
services des droits décisionnels. Définir les
actifs et meilleures pratiques de création
organisationnelle.
Définir des services métiers de valeur
pour la modélisation des processus
métiers, des services d'informations et des
meilleures pratiques pour identifier et
définir des services partagés
Figure 4.15 : Centre d’excellence pour la gouvernance SOA
Se référer au chapitre 7 pour plus de détails sur les responsabilités liées aux fonctions
décrites.
91
SOA for Profit
Si nous avons mis l’accent, à juste titre, sur l’importance de la gouvernance dans
la mise en œuvre de la SOA, celle-ci ne constitue pas le seul facteur de succès.
Comme nous l’avons déjà indiqué, une vue d’ensemble précise de la valeur métier
et des objectifs de la SOA est indispensable pour pouvoir accéder aux compétences appropriées en matière de création, de mise en place, de mise en œuvre et de
gestion de la SOA. La communication et le transfert des compétences nécessitent
également un intérêt particulier. Mais l’échec est garanti si aucun concept clair
n’a été défini. Le timing est fondamental, comme nous allons le voir.
4.9 Comment démarrer dans la politique de gouvernance SOA
Élevée
Compétence
en matière de
gouvernance
d’entreprise
Bonne
préparation
Prêt
Basse
Comme nous l’avons déjà mentionné dans ce chapitre, des stratégies et une
politique de gestion s’imposent absolument dès que les choses se compliquent. Mais convient-il de mettre en place un concept de gouvernance lorsque tout va mal ? Ce n’est pas judicieux. De même, il n’est pas utile de
définir un concept de gouvernance de grande envergure avant le premier
projet. En effet, sans une connaissance pratique préalable de la SOA, il est
pratiquement impossible de déterminer à l’avance de manière précise tous
les rôles, les responsabilités, les mécanismes de contrôle et les stratégies. La
gouvernance SOA est le fruit d’un processus d’apprentissage où prévalent
les devises du just in time (juste à temps) et du just enough (juste assez). En
d’autres termes, le concept de gouvernance doit être mis en place parallèlement à la définition et à la mise en œuvre de la SOA au sein de l’entreprise.
Il est en effet essentiel d’anticiper quelque peu les besoins. Autrement dit,
au lieu de réagir face aux problèmes, vous devez être proactif et anticiper.
Sensibilisation
Très risqué
Localement
Au niveau de
l’entreprise
Niveau de mise en œuvre de la SOA
Figure 4.16 : Niveaux de gouvernance SOA
92
4 Gouvernance ou chaos
Comme nous l’avons déjà indiqué, la gouvernance SOA n’est pas un élément
distinct mais plutôt une part intégrante de la gouvernance d’entreprise. Sur
la Figure 4.16, plus la compétence en matière de gouvernance d’entreprise
est réfléchie, plus les chances de réussite de la SOA à l’échelle de l’entreprise
seront importantes.
La Figure 4.16 montre qu’à mesure que le niveau d’agrégation augmente au
fil de la mise en œuvre de la SOA, il devient crucial de disposer d’une fonction
compétente en matière de gouvernance d’entreprise. Si le développement de
cette fonction est légèrement en avance sur le reste, aucun problème; cela
signifie que la structure est bien préparée pour la mise en œuvre au sein de
l’entreprise. Mais, dans le cas contraire, si l’on débute la mise en œuvre de la
SOA à l’échelle de l’entreprise sans aucune compétence appropriée dans le
domaine, cette démarche sera périlleuse. En effet, vous risquez de vous heurter à une forte prolifération de services, à une complexité accrue ou à un
surcoût de gestion et de maintenance, sans pouvoir tenir la promesse principale de la SOA, à savoir d’améliorer l’agilité et la souplesse de l’entreprise.
Si la mise en œuvre de la SOA est plus modeste, il est essentiel d’acquérir les
connaissances et l’expérience requises non seulement en ce qui concerne la
SOA, mais aussi la gouvernance SOA, et donc implicitement la gouvernance
d’entreprise. Au départ, vous devez accorder un intérêt approprié aux stratégies et aux mécanismes pour pouvoir réussir. Naturellement, libre à vous de
déterminer s’il est recommandé ou non de mener une SOA de faible envergure au sein de l’entreprise. La seule justification possible est que vous allez
mettre en place des modèles pilotes pour acquérir de l’expérience. Néanmoins, si vous souhaitez profiter de la SOA, vous devez vous placer dans un
contexte plus large. Débattre de la gouvernance d’entreprise est un bon moyen
d’y parvenir. Néanmoins, cela ne signifie pas qu’il faille mettre en œuvre une
SOA de façon immédiate et avec fracas. La meilleure façon de mettre en
œuvre la SOA est de procéder de façon progressive, par l’intermédiaire d’un
projet, mais dans tous les cas, en suivant la trame du concept de gouvernance
d’entreprise. C’est la raison pour laquelle ce concept doit être mis en œuvre
de manière proactive.
Si la SOA est appliquée à l’ensemble de l’entreprise, la gouvernance d’entreprise nécessite une certaine maturation. Faute de quoi, l’entreprise se trouvera confrontée à un problème, car le concept devra être mis en œuvre dans
le cadre des programmes et des projets SOA ou parallèlement. Une telle
démarche représente une surcharge dans la mise en œuvre de la SOA.
93
SOA for Profit
Mécanismes de gouvernance
Dans l’exemple qui suit, un certain nombre de mesures de gouvernance ont été prises
pour la mise en œuvre de la SOA au sein d’une entreprise qui pense et travaille en
accordant une grande confiance à l’infrastructure. La SOA a été introduite dans
l’entreprise en une seule fois pour en finir avec la formation des silos. Les exigences
vis-à-vis de la gouvernance SOA ont été considérables.
Pour définir le principe de gouvernance SOA, les points de départ étaient les suivants :
• Cette entreprise ne pense pas (encore) en termes de processus.
• La SOA n’a pas (encore) été introduite au niveau de l’activité.
• Il existe un département Architecture d’entreprise (AE). Ce département possède
la connaissance des processus métiers de l’entreprise et de tout le secteur.
• Les analyses d’information et de service sont inextricablement liées à l’analyse
des processus.
• Le département AE est l’organe qui gère tous les services.
• Le développement des services s’effectue suivant le principe de la priorité au
contrat (Contract First). En d’autres termes, le contrat de service (descriptif) est
formulé en amont et le service est créé ensuite.
Les mécanismes mis en place dans le cadre de la gouvernance SOA sont les sui­
vants :
Architecture de démarrage du projet de service
Le département AE prescrit les services à réutiliser pour chaque projet, les services
à réadapter et les services à introduire en proposant un descriptif exhaustif sur la
base du principe de la priorité au contrat. Ainsi, un projet ne détermine pas l’organisation future du service. Le département AE prend en compte le processus métiers
et y ajoute le potentiel de réutilisation (aucune analyse exhaustive de tous les processus métiers possibles, mais une simple approche guidée par le bon sens). Si
l’architecture de démarrage du projet est déjà en place, elle sera complétée par des
services.
Budget des services de marchandises
Sans un budget distinct pour les services réutilisables, les discussions au sein de
l’entreprise seront sans fin dès qu’un projet nécessitera des investissements sur des
éléments qui peuvent être réutilisés. Afin de favoriser cette réutilisation, l’entreprise
accepte de consacrer entièrement un budget à cette fin (services de marchandises).
Enfin, le service d’architecture de démarrage projet est décisif dans la définition
d’un service réutilisable. Même en l’absence de budget, un portefeuille adapté de
94
4 Gouvernance ou chaos
services sera garanti par l’architecture de démarrage projet. Ainsi, le budget facilite
les choses mais c’est l’architecture de démarrage projet qui est décisive. C’est le
variant le plus petit dans l’entreprise. Aucune alternative n’est possible car tout
autre choix donne des libertés qui entraînent la formation de nouveaux silos.
Division des projets
Dans cette entreprise, il a été décidé de séparer les projets consommateurs et les
projets fournisseurs. Le projet consommateur nécessite certains services, d’ailleurs
prescrits dans l’architecture de démarrage de projet. La méthode consiste à établir
deux sous-projets : un sous-projet application consommateur et un sous-projet fournisseur. Le sous-projet application consommateur est destiné à la fourniture d’une
application opérationnelle. Quant au second sous-projet, il concerne la fourniture de
services pour le projet application consommateur. Les deux sous-projets peuvent être
initiés en même temps suivant le principe de la priorité accordée au contrat. Le budget du fournisseur est issu du budget spécial consacré aux services de marchandises.
Dans cet exemple, l’entreprise a la chance de bénéficier d’une compétence dans la
fonction d’architecture d’entreprise. Cette fonction se voit attribuer ici un rôle important dans le contexte de gouvernance SOA.
4.10 Synthèse
Il apparaît que la gouvernance SOA et, de fait, la gouvernance d’entreprise
jouent un rôle majeur pour réussir la mise en œuvre de la SOA. Sans une
gouvernance adaptée, la mise en œuvre échouera, les opportunités de réutilisation seront quasi-inexistantes, voire nulles et, les services étant conçus et
achetés de manières différentes, il en résultera des systèmes informatiques
complexes, onéreux et très inefficaces.
La mise en œuvre de la gouvernance d’entreprise n’est pas seulement la
condition préalable au succès de la SOA ; elle augmente aussi les chances que
les initiatives stratégiques donnent lieu à des mises en œuvre réussies. Avec
la gouvernance et l’architecture d’entreprise, les changements peuvent s’effectuer de manière cohérente et logique.
Les principaux domaines de la gouvernance SOA sont la gestion des portefeuilles de services, la gestion des cycles de vie des services et le registre des
95
SOA for Profit
services. La gestion des portefeuilles empêche toute croissance non maîtrisée
du portefeuille de services. Par la gestion des cycles de vie des services, les
services sont supprimés du portefeuille dès qu’ils ne sont plus nécessaires.
Enfin, le registre des services indique les services disponibles ; ce registre est
crucial pour les réutilisations.
L’architecture d’entreprise constitue un autre élément essentiel de la gouvernance d’entreprise. Il incombe à l’architecte d’entreprise de dépasser les limites des business units et des silos informatiques pour obtenir un ensemble
optimal de services au sein de son organisation. L’architecture d’entreprise
dynamique constitue ainsi un modèle pragmatique. Les principes, directives
et modèles de SOA adaptés ne sont mis en place que s’ils correspondent à des
objectifs qui justifient le choix de la SOA.
Mettre en œuvre un concept de gouvernance SOA consiste à déterminer les
rôles et les responsabilités ainsi que les mécanismes de stratégie de gestion.
Mais surtout, la gouvernance SOA est destinée à améliorer les compétences
en matière de gouvernance et d’architecture d’entreprise. Seule une maturité
des compétences dans ces domaines vous permettra de tirer parti de la SOA.
96
5 Repenser votre activité
5.1 Introduction
Votre entreprise a-t-elle déjà envisagé d’externaliser certains services ? Ou
même de traiter avec une société offshore ? Avez-vous pensé à externaliser
certaines tâches vers une autre unité ? Telle est la finalité de la SOA : un partage des services au sein de l’entreprise dans lequel la localisation des services importe peu tant que le niveau de service fourni est conforme aux attentes. Une partie du processus en cours d’exécution dans votre unité peut être
pris en charge par un service assuré lui-même par une autre unité, voire en
externe.
L’analogie avec l’externalisation est intéressante pour une autre raison : elle
met en évidence le niveau d’abstraction que vous devez appliquer à votre
entreprise pour définir correctement une SOA. Pour ce faire, vous devez envisager les opportunités de réutilisation et les services au niveau de l’activité.
Vous devez aussi considérer votre société comme un réseau de personnes et
d’unités qui se fournissent mutuellement des services. Enfin, vous devez identifier les principaux composants de votre organisation. Dans ce chapitre, nous
allons vous expliquer comment adopter une approche orientée services.
Penser à votre entreprise à un certain niveau d’abstraction ne requiert pas
un génie hors du commun et n’est pas une nouveauté : on parle depuis longtemps déjà de l’optimisation de l’activité, avec des concepts comme les centres
de services partagés ou les fonctions du personnel pour les ressources humaines, l’impression ou les communications. Comme avec les autres modes d’optimisation, il est utile d’observer ce que les autres ont fait. Dans la SOA, cela
signifie étudier les modèles industriels émergents qui sont des modèles d’architecture tout faits et définis pour un secteur industriel donné.
Pour tirer le meilleur parti de la SOA, votre entreprise doit être « orientée
services » également au niveau métier. De cette manière, elle basculera aisément du concept d’optimisation métier à celui d’innovation du business model
en trouvant de nouveaux moyens d’exploiter son potentiel au service des
clients.
97
SOA for Profit
Dans ce chapitre, nous allons vous présenter les méthodes d’approche qui
vous aideront à mieux identifier les éléments et les services de base et à en
exploiter la valeur. Nous évoquerons le potentiel des modèles industriels et
leur mode d’utilisation. Nous vous donnerons également des outils et des
exemples pratiques pour vous permettre d’acquérir une vue d’ensemble et
de définir des priorités plus rapidement en optimisant votre activité à partir
d’une architecture orientée services.
5.2 Quel est votre business model ?
Un business model, ou modèle d’entreprise, est une description abstraite de
votre activité dans un but précis. Elle décrit la façon dont vous travaillez (ou
vous souhaitez travailler). En général, il n’existe pas de modèle unique couvrant tous les besoins, mais un ensemble de modèles correspondant à des
vues différentes. En termes d’architecture d’entreprise, ces modèles sont
regroupés au sein d’une « l’architecture métiers » et destinés à la fois à l’innovation dans la branche d’activité et au développement de solutions informatiques.
Un business model n’est intéressant que s’il s’intègre dans votre entreprise et
qu’il a un but. Pour trouver le modèle optimal, vous devez analyser l’entreprise en vous aidant, si possible, de modèles de société similaires ou de modèles industriels susceptibles de faciliter le travail. Afin que les modèles soient
exploitables pour les transformations, ils doivent se composer d’ensemble de
blocs bien définis, conçus pour durer et parés à tous changements. La configuration des blocs peut varier suivant les processus et les produits ; mais les
éléments de base restent identiques. Ici, nous observons une grande similitude avec l’architecture orientée services où les services doivent être assez
statiques, mais néanmoins modulables en une multitude de solutions pour
répondre facilement aux évolutions.
Dans un business model, les éléments doivent être décrits et définis de la
même manière que les « services », c’est-à-dire aussi indépendamment les
uns des autres que possible, avec des interfaces clairement définies, tout en
reflétant le fonctionnement réel d’un métier. Le modèle offre alors les
mêmes avantages que les logiciels avec les services : il répond aux changements.
98
5 Repenser votre activité
Pour trouver les business models adaptés à votre entreprise, vous devez étudier la situation, analyser la vision et la stratégie mises en œuvre et vous
pencher sur les modèles et les standards SOA existants. Vous aboutirez ainsi
à des business models personnalisés, basés sur la SOA.
Une méthodologie grandeur nature
Dans ce chapitre, nous allons prendre l’exemple d’un fournisseur mondial de produits
plastiques afin de présenter les différents modèles et leur interaction. Les exemples
sont tirés d’un projet grandeur nature mené chez un fabricant au cours du printemps
2006. Nous avons ainsi pu observer à quoi pouvaient aboutir certains modèles. Naturellement, les modèles sont aisément adaptables à votre secteur d’activité, que vous
travailliez dans la finance, la santé ou toute autre industrie.
Retour clients
Au début du projet de transformation, nous avons débattu de la méthode d’analyse
et de la modélisation des métiers avec le client. Comme le secteur concerné est fortement orienté processus, nous pensions que l’introduction d’une nouvelle approche
orientée services prendrait du temps. À notre grande surprise, la méthode (qui était
très novatrice pour ce secteur) a semblé porter ses fruits ; lors d’une série d’entretiens
réalisée avec chaque directeur du groupe et avec d’autres acteurs clé, nous n’avons
pas eu à attendre plus de 15 minutes en moyenne pour entendre des remarques telles
que « c’est une bonne façon de voir notre activité ».
Nous avons aussi entendu des commentaires tels que « c’est seulement une question
de bon sens, pourquoi faire différemment ? » ou encore « nous travaillons effectivement comme cela, mais le support de nos applications informatiques actuelles ne
l’intègre pas ». Outre le fait que la culture organisationnelle de l’entreprise est un
facteur essentiel, le côté pratique et naturel du modèle a été l’élément déterminant
de cette acceptation rapide.
5.3 D’une entreprise orientée fonctions à une entreprise orientée services
Aujourd’hui, la plupart des entreprises sont orientées fonctions. Suivant les
théories de Frederich Winslow Taylor (1856-1915) et Luther Gulick (18651918), elles sont traditionnellement divisées en départements composés
d’unités homogènes. Ces organisations fonctionnelles avec départements et
unités (cf. Figure 5.1) étaient parfaites au temps où les processus métiers
s’effectuaient au bas de l’échelle ou au niveau des nœuds finaux. Pour opti-
99
SOA for Profit
miser ce type d’organisation, nous avons analysé toutes les activités pour les
affecter ensuite à un groupe, sans affecter l’homogénéité de chaque division
organisationnelle.
Division
Personnel
Direction
Personnel
Division
Personnel
Division
Personnel
Unité
Unité
Unité
Unité
Unité
Unité
Figure 5.1 : Business model fonctionnel de base
De cette structure découle directement l’architecture informatique dite « en
tuyaux de poêle » ou en « silos ». Il existe un ensemble unique d’applications pour
chaque division et unité, ce qui génère une maintenance onéreuse et un support
complexe, sans oublier une très faible flexibilité au niveau de l’entreprise.
L’heure du changement a sonné
Quelle tendance se dessine depuis un certain temps et va aller crescendo ?
C’est un phénomène de globalisation accompagné d’une évolution plus rapide
qui s’opère. Cela signifie, entre autres, que les processus initialement locaux
sont désormais décalés vers le haut du modèle, ce qui les rend plus centralisés et étendus à l’échelle de l’entreprise. Nous observons une évolution en
faveur du partage des applications et des processus entre les unités organisationnelles. En fait, les modèles organisationnels de base ne correspondent
plus aux entreprises d’aujourd’hui, qu’elles soient publiques ou privées.
L’entreprise orientée services
Ce type d’entreprise est basé sur un ensemble commun de services métiers.
Les services sont rattachés à des potentiels d’activité qui correspondent aux
potentiels de haut niveau d’une entreprise. Si nécessaire, les potentiels sont
alors regroupés dans différents domaines métier qui constituent les plus gros
blocs des différents business models de haut niveau. Pour concevoir des solutions, la méthode consiste à définir des processus en s’aidant des services
métiers ou de leur abstraction représentée par les blocs.
100
5 Repenser votre activité
Les services traitent l’aspect du QUOI et les processus celui du COMMENT.
Un service métiers est réalisable par de nombreux potentiels, un potentiel
pouvant faire partie de plusieurs domaines. La Figure 5.2 représente une
entreprise orientée services.
Processus
Domaines
Ventes
Créer
activités
Production
Logistique
Traiter
commandes
Planifier
production
Produire
plastique
Traiter
plastique
Distribuer
produits
Gérer
entrepôts
Enregistrer
commande
Afficher
stock
Recevoir
paramètres
Recevoir
paramètres
Transport
Stocker
marchandise marchandise
Attribuer
capacités
Optimiser
production
Contrôler
processus
Contrôler
processus
Décharger
marchandise
Finance
Fournir
services
Assurer
paiement
Charger
marchandise
Envoyer
facture
Confirmer
envoi
Contrôler
APL
Capacités
Enregistrer
prospect
Services métiers
Actualiser
plan
Préparer
chargement
Envoyer
marchandise
Figure 5.2 : Entreprise orientée services
Un processus métiers s’opère avec l’aide des services métiers contenus dans
les potentiels métiers. Les domaines sont les entités organisationnelles qui
effectuent les services métiers avec ou sans le support informatique.
La cartographie d’une organisation complète comportant un nombre accru
de processus, est naturellement plus complexe. Par ailleurs, les services
métiers peuvent couvrir plusieurs potentiels (non illustrés sur la figure). Par
exemple le service « Consulter stocks » est utilisé pour planifier la production, mais également pour décider où stocker les marchandises dans l’entrepôt.
5.4 Éléments d’un business model dynamique
Les éléments constitutifs d’un business model doivent rester assez stables
dans le temps, le modèle devant néanmoins décrire l’activité de manière précise. Les niveaux d’abstraction que nous appliquons lorsque nous réfléchissons à une organisation, sont les domaines métiers, les potentiels (« toutes les
101
SOA for Profit
choses qu’une entreprise peut être capable de faire »), les processus et unités
et, enfin, les lignes de services qui fournissent en dernier lieu le produit ou le
service final de l’entreprise.
Cartographie du domaine métier
La cartographie est le niveau d’abstraction le plus élevé. Les domaines sont
personnalisés en fonction des exigences présentes (et prévisibles) de l’activité. Un domaine est un bloc de business models et de processus de haut
niveau ainsi qu’un contexte/une démarcation pour une fonction essentielle
ou prioritaire.
Ici, les domaines présenteront des caractéristiques différentes comme les
unités organisationnelles, les sous-processus, les fonctions de support, les
fonctions prioritaires ou les fonctions de contrôle globales. Le nombre de
domaines à définir et de caractéristiques à utiliser dépend entièrement de
l’entreprise existante, de sa stratégie présente et future ainsi que de son activité et des services informatiques en place. La Figure 5.3 illustre une division
simple mais courante en domaines.
Approvisionnement
Production
Planification
et exécution
livraison
GRC
et ventes
Management
de la qualité
Planification
principale
Finance,
comptabilité et
contrôle de gestion
Gestion
d’entrepôts
Développement
de produits
Planification et
analyse
des marchés
Figure 5.3 : Cartographie du domaine métiers
Cartographie des potentiels
De manière générale, les domaines sont une structure de classement normalement rattachée à la fonction organisationnelle chargée des services métiers,
le « QUI ». Pour obtenir une vue davantage orientée action, nous devons passer à la cartographie des potentiels, le « QUOI de haut niveau ».
102
5 Repenser votre activité
Maintenance
installations
Planification
production
Gestion
commandes
commerciales
Gestion
de la
relation client
Management
de la
qualité
Achats
Fabrication
plastique
Planification
livraisons
Ventes
Management
environnemental
Comptabilité
Traitement
plastique
Distribution
produits
Développement
marché
Développement
produits
Contrôle
de gestion
corporate
Consolidation
financière
Gestion
des entrepôts
Planification
logistique
Facturation
Figure 5.4 : Cartographie des potentiels (à un stade anticipé dans la réalité)
Cartographie des processus ou unités
L’ensemble des domaines ou potentiels compilés dans un diagramme comme
celui de la Figure 5.4 ne constitue pas une plus-value en soi, mais représente
simplement un regroupement aléatoire. Il doit être placé dans un contexte
qui définira comment les éléments apportent une valeur ajoutée. Le contexte
doit être un processus ou un modèle unitaire.
Gestion de la
relation client
et vente
Planification et
exécution
livraison
Production
Gestion
des entrepôts
Finance,
comptabilité et
contrôle de gestion
Figure 5.5 : Contexte des processus basé sur les domaines
Sur la Figure 5.5, le processus de haut niveau indique comment rattacher les
domaines à un contexte ; cela recouvre l’ensemble du processus depuis la
vente jusqu’à l’obtention d’un paiement. Ce même processus basé sur des
potentiels donne un modèle prescriptif davantage orienté vers l’action, comme
Control Strategic KPI:s
celui de la Figure 5.6.
Monitor Delivery process
Créer
activité
Traiter
commande
Planifier
production
Fabriquer
plastique
Traiter
plastique
Gérer
entrepôts
Distribuer
produits
Figure 5.6 : Contexte des processus basé sur les potentiels
103
SOA for Profit
Business model d’une ligne de services
Vous pouvez aller encore plus en profondeur dans le processus si vous le
rattachez à une ligne de services, un scénario spécifique à la fourniture de
certains paramètres de sortie du processus métiers de base (une offre de
services).
Les lignes de services sont sans aucun doute le meilleur moyen, dans la plupart des cas, d’intégrer les potentiels et les services dans leur véritable
contexte. La représentation des domaines/potentiels sous la forme de blocs
est très adaptée à la description et la mise en place de flux de lignes de services.
Suivre les KPI stratégiques
Suivre le processus de fourniture
Créer
activité
Traiter
commande
Planifier
production
Fabriquer
plastique
Gérer
entrepôts
Traiter
plastique
Gérer
entrepôts
Distribuer
produits
Terminer
fourniture
Figure 5.7 : Business model d’une ligne de services
La Figure 5.7 présente un exemple de ligne de services : fourniture de « pots
de yaourts à un client final qui commercialise des produits de santé conformément à un contrat de niveau de service (SLA) spécifique ». Dans le processus détaillé, les potentiels mettent en évidence toutes les étapes majeures
requises pour la fourniture de cette offre de services ; c’est la ligne de services.
Cette ligne se décompose comme suit :
1. La souscription du contrat de services s’effectue au niveau du bloc Créer
activité.
2. Les commandes sont réceptionnées et gérées dans le bloc Traiter commandes.
. Comme le SLA nécessite la gestion de produits en stock, la production doit
être planifiée pour répondre à ce cas de figure particulier.
. La première étape de production consiste à fabriquer la matière plastique
de base.
. La seconde étape est le traitement du plastique par une pression de formage dans des pots et l’ajout d’une surface imprimable, le tout suivant la
spécification produits définie contractuellement.
. Les pots sont acheminés dans un entrepôt proche du client afin de garantir
le SLA.
7. Les pots sont livrés de l’entrepôt à l’imprimeur du client sur demande,
conformément au SLA.
104
5 Repenser votre activité
. Le fournisseur de services est payé en fonction des produits livrés et des
conditions définies contractuellement.
. La fourniture est achevée après le suivi de qualité et une éventuelle gestion
des réclamations.
Pendant l’intégralité du processus, les KPI stratégiques et le processus de
fourniture font l’objet d’un suivi.
À ce degré de détail, nous sommes au niveau le plus bas des business models
basés sur les processus, un concept que nous appellerons « business model
de ligne de services ».
Sur ces schémas, vous pouvez utiliser les éléments de base (potentiels et
services) pour définir n’importe quel modèle, par exemple en considérant le
métier suivant d’autres axes que ceux du « processus ». Ici, le business model
ne constitue qu’une trame. Si vous mettez en place une solution, le processus
sera beaucoup plus détaillé, mais restera toujours ancré sur cette trame.
5.5 Comment identifier les éléments de votre business model dynamique
Nous avons vu les éléments que nous pouvons utiliser pour établir un business model dynamique et les cartographies que nous pouvons créer. Comment
identifier les éléments spécifiques aux modèles de votre entreprise et êtesvous à même de repenser votre activité sur la base de ces modèles ?
Tout d’abord, vous devez vous orienter vers la stratégie métier qui vous aidera
à dresser une image du futur (proche), à trouver les éléments fixes de l’entreprise et à les séparer du reste. L’activité doit réagir aux changements avec
des modèles pour faciliter ces transitions, la vitesse de changement attendue
devant être définie par la stratégie (elle-même conditionnée par la vision
métiers à long terme).
Ensuite, il existe plusieurs points de vue de l’entreprise qui vous aideront à
identifier les blocs de conception SOA ainsi qu’à alimenter le processus de
restructuration. Ces points de vue sont les suivants :
•
chaînes de valeur
•
processus associés
•
stratégie en cascade
105
SOA for Profit
Ces points de vue sont utiles pour amorcer les débats du fait qu’ils sont basés
sur l’activité et la stratégie, à un bon degré d’abstraction. L’expérience montre
que le fait de définir les différents composants de modélisation et leurs limites
n’est qu’une histoire de temps et d’engagement. Le temps requis dépend largement de votre façon d’appréhender et d’accepter l’idée de modèles. Cela
sera plus rapide si vous utilisez les points de vue décrits ici de manière structurée. Ces points de vue garantissent également un bon degré d’abstraction.
En effet, en vous plaçant au degré d’abstraction requis, vous éviterez des
débats excessivement détaillés et sans fin. S’en tenir au degré requis est un
facteur clé de réussite dans la création des éléments de base de vos business
models.
Après avoir étudié l’entreprise à partir des points de vue évoqués, vous pourrez élaborer une cartographie des potentiels (le modèle le plus intéressant
pour la SOA) et définir les services.
Suivre la chaîne de valeur
La chaîne de valeur est le premier point de vue à utiliser. En effet, vous aurez
plus de facilité à identifier les fonctions et les aspects clé de l’activité en les
rapportant à cette chaîne.
La Figure 5.8 est une chaîne de valeur courante. Elle illustre les potentiels de
base (domaines) autour desquels s’articulent le processus métiers de base et
les interactions possibles de processus de gestion et de support.
Gestion de l'activité & Suivi de stratégie
Alignement de planification, contrôle et stratégie d'activité
Commercialiser
l'intelligence
Développer
produit
Ventes
Production
Distribution
Livraison
proche
Fonctions support
Figure 5.8 : Chaîne de valeur avec fonctionnalités clé associées
En débattant de la chaîne de valeur, vous pourrez mettre en lumière plusieurs
méthodes de fourniture des produits. Définir un business model, comme celui
illustré ci-dessous, est un exercice intéressant. La Figure 5.9 représente un
cas particulier avec deux principaux flux de fournitures de produits : les biens
et les services.
106
5 Repenser votre activité
Gestion de l'activité
Planification
et
développement
métier
Production
Développer
produits
Distribution
Marché
Ventes
Fourniture
de services
Fonctions support
Figure 5.9 : Business model de haut niveau avec les domaines clé
Cette configuration est courante dans de nombreuses entreprises, et dans
certains cas il est évident que biens et services purs ne peuvent pas être gérés
de la même manière. De nombreuses sociétés sont tombées dans le piège en
utilisant un système conçu pour des « marchandises » pour la gestion de produits basés « services ». Une telle approche aboutit généralement à une solution standard sans valeur. À noter un autre piège que vous pouvez éviter avec
le modèle ci-dessus : les nouvelles solutions standards acquises pour un
domaine spécifique ont tendance à étendre leur fonctionnalité au-delà des
limites définies.
Un business model de ce niveau est intéressant s’il couvre les domaines fédéraux ainsi que les différentes lignes de service clé. L’avantage de ce modèle
est qu’il peut servir de référentiel pour la démarcation et la normalisation des
domaines de systèmes informatiques.
Observer les processus associés
À ce stade, lorsque vous aurez étudié et défini les abstractions métiers les plus
élevées, il sera temps d’aborder un aspect plus pratique de l’activité. L’étape
naturelle suivante consiste à utiliser l’aspect des processus associés. Le point
de départ est la chaîne de valeur.
Les débats doivent s’orienter vers les procédés associés utilisés ou requis
pour satisfaire le processus métiers à un niveau plus détaillé. Le résultat de
l’exercice sera une cartographie semblable à celle de la Figure 5.10.
107
SOA for Profit
Gestion d'activité & Suivi de stratégie
Alignement de planification, contrôle et stratégie d'activité
Commercialiser
l'intelligence
Développer
le produit
Ventes
Production
Distribution
Fourniture
proche
Fonctions de support
Du concept à l'offre
de marché
Du marché au client
De la commande au paiement
Prévisions pour la fourniture
d'une capacité logistique
Figure 5.10 : Processus associés
Les blocs fléchés représentent les principaux processus associés de l’activité,
positionnés par rapport à la chaîne de valeur. Au fil de votre avancement avec
les différents modèles ci-dessus, vous devrez revoir et actualiser la cartographie des potentiels.
Élaborer une stratégie en cascade
Pour analyser l’entreprise, une autre approche constructive consiste à considérer la stratégie métiers comme l’élément clé. Vous pourrez ensuite déterminer comment mettre en œuvre la stratégie dans ce contexte. Quelles mesures doivent prendre les unités pour appliquer la stratégie ? Comment les
activités combinées soutiennent-elles la stratégie ? Cela vous aidera à identifier les composants de l’entreprise qui présentent un intérêt stratégique (à
déterminer l’unité qui contribue effectivement à la stratégie et les unités
n’ayant quasiment aucun lien avec cette stratégie). Vous pourrez ainsi mieux
vous rendre compte de la façon dont la stratégie (et l’innovation) est gérée au
sein de votre entreprise. La définition de la stratégie est-elle un processus
continu ou est-elle redéfinie une fois tous les trois ans ? La stratégie fait-elle
explicitement partie intégrante de votre structure de gouvernance ?
Établir une cartographie des potentiels
Après avoir utilisé ces différents points de vue, vous obtiendrez à l’issue de
toutes ces sessions, outre les modèles eux-mêmes, le fondement de modélisation SOA ou plus précisément la cartographie des potentiels.
108
5 Repenser votre activité
Gérer
installation
Planifier
production
Traiter
commandes
Gérer
la relation
client
Gérer la qualité
Acheter
matières
premières
Fabriquer
plastique
Planifier
les
livraisons
Souscrire
contrat
Gérer les
problèmes environnementaux
Gérer
livres de
comptes
Traiter
plastique
Distribuer
produits
Développer
marché
Développer
produits
Suivre
activité
Consolider
finances
Gérer
entrepôts
Planifier
logistique
Contrôler flux
de trésorerie
Figure 5.11 : Ensemble des potentiels : une cartographie des potentiels
Des points de vue différents ayant été utilisés et étudiés, la cartographie des
potentiels est plus ou moins validée à ce stade. Pour aller encore plus loin,
vous pouvez mettre en place chaque processus associé à partir des potentiels
définis. Si un potentiel manque, vous vous en rendrez compte à ce moment-là.
La Figure 5.12 est un exemple de processus associé.
Traiter
bons de
commande
Fabriquer
plastique
Traiter
plastique
Gérer
entrepôts
Distribuer
produits
Gérer livres
de comptes
Encaissement
Commande
Processus associé de la commande au paiement
Figure 5.12 : Processus associé obtenu à partir des potentiels prédéfinis
Le processus a été élaboré à partir des potentiels prédéfinis. À ce stade, la
cartographie pourra être validée, en particulier si des scénarios futurs ont été
abordés et définis.
Services
Dans ce processus de création d’une base SOA, l’étape ultime consiste à parcourir tous les potentiels et à identifier les services requis pour remplir les
principales tâches. Les potentiels intègrent les services métiers nécessaires
au cas par cas, comme l’illustre la Figure 5.13.
109
SOA for Profit
Achat matières premières
Service
métier
Service
métier
Service
métier
Service
métier
Service
métier
Gérer la relation client et
créer activité
Service
métier
Service
métier
Service
métier
Service
métier
Service
métier
Gérer entrepôts
Service
métier
Service
métier
Service
métier
Service
métier
Service
métier
Planifier
et exécuter livraison
Service
métier
Service
métier
Service
métier
Service
métier
Service
métier
Figure 5.13 : Ensemble choisi de potentiels dotés de services
Ici, vous décrivez également les flux d’information clé entrants et sortants en
termes de potentiels. Idéalement, vous devez définir les flux entrants et sortants pour chaque service métier. Si vous manquez de temps, vous vous
contenterez des services les plus importants.
Un monde de services
Lorsque vous aurez défini les services métiers, que vous les aurez placés
dans le contexte des potentiels et que vous aurez déterminé les propriétés
de haut niveau pour chaque potentiel, vous disposerez enfin de la trame
requise pour établir des business models et mettre en œuvre des processus.
En utilisant les éléments décrits jusqu’à présent, vous pouvez modéliser
votre activité et l’optimiser pour en faire un univers dynamique et compétitif.
Une entreprise véritablement orientée services se compose de blocs (services et/ou potentiels) utilisables pour créer de nouvelles offres et lignes de
services. Les outils sont destinés à l’assemblage des processus de vente et
de fourniture des offres de services ainsi qu’à la simulation d’études de
faisabilité et de la valeur d’entreprise. Les blocs de construction sont des
composants SOA activés par les systèmes informatiques, qui accélèrent le
processus d’ajout ou de modification à la fois des applications et des lignes
de services.
110
5 Repenser votre activité
Une autre méthode de transformation métier stratégique : le Concept Component Business Modelling (CBM) d’IBM
Le concept de Component Business Modelling d’IBM (CBM)™ est une méthode de
création d’architecture métier actuelle et future [IBM Global Business Services 2006c].
Dans CBM, les activités métiers sont regroupées en composants autonomes. Ces
composants sont définis comme « partie d’une entreprise qui intègre des activités
similaires et peut fonctionner de manière indépendante ».
La méthode permet d’aboutir à des cartographies organisationnelles et à la définition
de priorités sur la base de modèles, comme le montre la Figure 5.14.
Compétences
Direction
Canaux
Logistique
Gestion
d'entreprise
Planification marchandises
Stratégie canaux
Création réseaux
Stratégie d'entreprise
Planification canaux
Constitution stock
Planification assortiments
Stratégie pour les
biens immobiliers
Création entrepôts
Planification
d'entreprise
Clients
Produits/
Services
Niveau de
responsabilité
Stratégie
service
clientèle
Stratégie marketing
Planification espace
Planification promotion
Création Internet
Création catalogue/
centre d'appels
Planification flux
de demandes
Flux produits
Gestion canaux
Routage entrant
Programmation
Gestion travail
Développement produits
Approvisionnements
Niveau de responsabilité
Contrôle
Gestion campagne
Affectation
Gestion inventaire/OTE
Gestion services
Prévisions demandes
Gestion prix
Gestion commandes
Construction
d'immeubles
et gestion
d'installations
Gestion contenu
Gestion fournisseur
Exécution
Service clients
Communication
clients
Marketing
Gestion articles
Prévention pertes
Gestion commandes
Gestion PO
Gestion inventaire
Réapprovisionnement
Gestion
marchandises
Gestion recettes/
douanes
Gestion prix/
signatures
Publicité
Relations publiques
Source : IBM Business Consulting Services
Planification
financière
Gestion performance
d'entreprise
Planification réceptions
Gestion trésorerie
et risques
Planification livraisons
Conformité juridique
et réglementaire
Planifications
transporteurs
Contrôle d'inventaire
Encaissements et banque
Gestion entrepôts
Comptabilité et
suivi financiers
Gestion transport
Approvisionnement
indirect
Gestion produit
Gestion fournisseurs
Planification
financière
Gestion flotte
Logistique inverse
Gestion RH
Système et opérations
informatique
Composant clé
Figure 5.14 : Cartographie métiers composants
Pour définir chaque composant, vous devez attribuer cinq dimensions, comme le
montre la Figure 5.15.
111
SOA for Profit
Gérer
Concevoir Acheter
Faire
Vendre
Diriger
Contrôler
Dimensions d'un composant métier
Objetif métier
Pourquoi existe-t-il ?
Exécuter
Activités
Mesures cohésives et
simples prises
régulièrement ?
Ressources
Actifs corporels et
ressources humaines
nécessaires ?
Gouvernance
Modes de gestion des
activités ressources ?
Services
Éléments adoptés et proposés à d'autres composants ?
Figure 5.15 : Les cinq dimensions d’un composant métier
5.6 De la structure en silos au partage des ressources
En organisant votre activité, vous allez vous heurter au problème des silos :
unités organisationnelles structurées en silos (plusieurs unités pouvant effectuer la même tâche, sans vouloir abandonner l’activité) et silos applicatifs.
Il existe des silos applicatifs car, dans le passé, les unités opérationnelles
étaient libres de concevoir des applications spécialement adaptées à leurs
besoins sans tenir compte des autres unités de l’entreprise. Les principales
caractéristiques de cette ancienne architecture étaient les suivants :
•
Chaque unité possède sa propre cartographie des applications.
•
Le niveau de standardisation est faible.
•
La souplesse face au changement est faible.
•
La possibilité de créer rapidement des solutions intégrées est entravée.
Grâce à la SOA, vous allez décomposer les silos et les remplacer par un modèle
mixte. De nombreux services importants seront partagés au sein de l’entreprise et quelques services resteront rattachés plus spécifiquement à une
entité donnée.
Quels potentiels centraliser ou pas ?
Le choix des potentiels à centraliser ou à partager a un impact immédiat sur
la liberté des entités dans l’entreprise.
Il est important de définir les potentiels communs et fédéraux (ou partagés)
du point de vue de l’entreprise. Une autre tâche majeure est de déterminer
quels sont les potentiels standards et les potentiels librement choisis au
niveau local. Le modèle de fédération résulte d’analyses menées et de déci-
112
5 Repenser votre activité
sions prises par rapport à ces deux aspects. Il prescrit les potentiels exécutés
au niveau global, les potentiels à piloter à partir de ce niveau et enfin, les
potentiels pouvant être librement choisis au niveau local de l’unité.
Le modèle suivant présente un exemple de potentiels au niveau global.
Fonctions métiers
Professionnel
Détail
Externe
Interne
Prévisions et planification centrale
Reporting groupe
Management de la qualité
Processus fédéraux
Gestion ventes & commandes
Figure 5.16 : Cartographie des potentiels fédéraux
Au niveau de l’unité, deux standards coïncident : le standard global et le standard local. Ici, vous pouvez recourir à la cartographie pour différencier les
potentiels à fournir localement et les potentiels partagés. Cette cartographie
permettra ensuite d’établir la future cartographie des applications.
Unité locale
Planifier
production
Fabriquer
plastique
Gérer
entrepôts
Gérer livres Acheter mat.
de comptes
premières
Traiter
plastique
Gérer
la qualité
Gérer
installation
Standard local
Standard fédéral
Figure 5.17 : Modèle de fédération locale
Les standards fédéraux sont définis au niveau de l’entreprise, l’objectif étant
que chaque potentiel ne soit soutenu que par une seule application au sein
de l’organisation. Pour le standard local, chaque unité peut choisir sa solution
tant qu’elle ne dépasse pas les limites des potentiels et qu’elle met en œuvre
les interfaces d’intégration standard (d’autres restrictions architecturales
comme les préférences en matière de plates-formes préférentielles et les
fournisseurs sélectionnés, peuvent s’appliquer).
Les modèles fédéraux dotés d’interfaces explicites aident l’entreprise à se
frayer un chemin sur la voie de la transformation en éliminant toutes les
caractéristiques inadaptées de l’ancienne architecture.
113
SOA for Profit
Du modèle au logiciel
Prenons maintenant l’un des potentiels de la figure précédente pour réaliser
un schéma plus détaillé. Ce schéma peut servir directement à sélectionner ou
à définir une solution informatique. À titre d’exemple, pour mettre en place
une solution de gestion d’entrepôts, le modèle détaillé des potentiels avec sa
population de services métiers constituera la spécification des exigences
fonctionnelles de haut niveau. Le modèle, avec les flux d’information entrants
et sortants pose les exigences d’intégration. Dans ce cas précis, il peut suffire,
d’un point de vue fonctionnel, de s’adresser à des fournisseurs susceptibles
de proposer une solution toute faite.
Interface d'intégration
Gestion d'entrepôts
Indiquer
marchand.
reçues
Recevoir
conseils
Indiquer
transfert
march.
Indiquer
stocks
Entrée
marchand.
Transfert
marchandises
Conditionnement
marchandises
Transbordement
Inventaire
stocks
Réparation
Sortie
marchandises
Gestion
palettes
Recevoir
instructions
Interface
physique
marchandises
Chargement routier
Chargement ferroviaire
Figure 5.18 : Modèle peuplé pour un potentiel choisi
De ce point de vue, si l’on ajoute des règles métiers et des exigences techniques spécifiques comme une interface Internet d’intégration basée sur les
services, tout fournisseur d’un système de gestion d’entrepôts pourra proposer comme solution une offre de base et une spécification.
5.7 Comment définir des priorités ?
Vous ne pouvez pas tout changer en même temps. Le modèle de maturité SOA
vous aidera à définir les aspects de votre activité et de votre organisation
informatique à optimiser. De même, vous devrez déterminer des priorités, en
commençant par les éléments dont l’amélioration fait appel au bon sens. Pour
cela, vous utiliserez des techniques dont voici quelques exemples :
114
5 Repenser votre activité
•
•
•
•
•
•
Matrice Gain/Facilité
Vous étudierez les investissements pour chaque domaine et chaque potentiel.
Classement des domaines/potentiels prioritaires
Définir un consensus entre les parties prenantes sur les potentiels ou les
domaines majeurs à traiter en priorité.
Analyse de la chaîne de valeur
Trouver un compromis entre les lignes de la chaîne de valeur.
Stratégie en cascade
Établir directement des priorités à partir de la stratégie métier globale.
Il est possible de combiner la plupart des techniques pour obtenir une vue
d’ensemble plus exhaustive des priorités. Les techniques de mise en place de
compromis vous aideront à définir des priorités et, en parallèle, à favoriser
une certaine sensibilisation et le développement d’une vision partagée pour
faciliter la mise en place et en accélérer le rythme. Ces démarches donneront
lieu à des discussions qui mettront en évidence les points critiques de votre
architecture.
La matrice Gain/Facilité
Cette matrice est un outil utilisé pour définir une solution ou un gain/facilité
de mise en œuvre. Les matrices dont les scores sont les plus élevés sur les
deux échelles sont clairement identifiées comme des solutions gagnantes et
comme les déclencheurs possibles d’une transformation.
Avantages
métier
Planifier capacité logistique
Traiter bon
de commande
Développer
produits
Planifier
production
Distribuer
produits
Créer
activité
Sécuriser
paiement
Facilité de mise en oeuvre
Figure 5.19 : Matrice Gain/Facilité
115
SOA for Profit
La matrice est utile pour définir la plupart des priorités communes au sein
d’un groupe. L’animateur formateur dispose d’un ensemble de potentiels. Le
groupe doit arriver à un consensus sur le positionnement de ses potentiels
dans la matrice. Ensuite, il est judicieux de noter les conditions sous-jacentes
à ce positionnement. En principe, chaque objet représenté dans la matrice
suscite des discussions intéressantes. Les participants peuvent avoir des difficultés à appréhender l’échelle sur l’axe. Pour résoudre ce problème, on peut
prévoir un exercice initial afin de faciliter la compréhension de l’axe et des
valeurs d’échelle. À l’issue de la session, les éléments gagnants identifiés
seront les potentiels les plus proches de l’angle supérieur droit de la
matrice.
Définir les domaines/potentiels prioritaires
Il s’agit d’une technique employée pour dresser la liste des potentiels inscrits
sur la cartographie à choisir en priorité. Normalement, vous devez procéder
suivant deux perspectives principales : les opportunités et les problèmes.
Les acteurs clé sont invités à voter au sein d’un atelier ou à l’occasion d’entretiens. Ils devront tout d’abord s’exprimer sur les potentiels qu’ils estiment
le plus à même d’évoluer (les opportunités) et deuxièmement, sur les potentiels les plus complexes (les problèmes). Le résultat sera compilé dans la
cartographie ou sur toute autre représentation basée sur les potentiels.
Gérer
installation
Planifier
produtcion
Traiter
bons de
commande
Gérer la
relation
client
Gérer
la qualité
Acheter
matières
premières
Fabriquer
plastique
Planifier
livraisons
Créer
activité
Gérer problèmes environnementaux
Gérer livres
de comptes
Traiter
plastique
Distribute
Products
Analyser
marché
Développer
produits
Contrôler
KPI
d’entreprise
Consolider
finance
Gérer
entrepôts
Planifier
logistique
Sécuriser
encaissements
Besoin de changement
Besoin de changement
Besoin de changement élevé
Figure 5.20 : Cartographie des potentiels
avec priorités de changement signalées par des couleurs
116
5 Repenser votre activité
Après le vote, il est intéressant de parcourir les résultats et d’en discuter. Le
fait de documenter la motivation de ces choix constitue un bon complément
à la cartographie des priorités ci-dessus.
Analyse de la chaîne des valeurs
Malgré sa simplicité, la chaîne des valeurs est une plate-forme assez intéressante de définition des priorités. Elle est parfaitement adaptée aux activités en
début d’atelier et à de rapides analyses. Où sont les problèmes ? Où sont les
opportunités ? Vous pouvez appliquer à la chaîne des valeurs et aux étapes
successives, le même exercice de vote que celui précédemment mentionné pour
définir les domaines/potentiels prioritaires. Pour aller plus en profondeur, vous
devrez rattacher chaque étape de la chaîne à ses potentiels. Les priorités seront
ensuite définies en termes de potentiels. La chaîne des valeurs peut servir à
récapituler les résultats quel que soit le niveau de détail du travail.
Métiers
Planification
Developper
nouveaux
produits
Processus de gestion métiers (y compris management de la qualité)
Marketing
Zone critique
Planifier
demande
Ventes
Opportunité à court terme
Production
Gestion
des
stocks
Distribution
Vente
Consommateur
Opportunité à moyen terme
Figure 5.21 : Chaîne des valeurs avec niveaux d’urgence
La Figure 5.21 fournit un exemple pris chez un grand fabricant mondial de
produits de consommation il y a quelques années. Le résumé de l’analyse
effectuée au niveau des sous-processus a été représenté sur une chaîne de
valeurs. Ici, le besoin de changement le plus urgent concerne les procédures
de distribution. Sur le plan de la transformation, la fonction Distribution a été
jugée prioritaire. Dans la pratique, un intérêt particulier a été accordé à une
meilleure intégration des services et à des changements de responsabilité.
Cette dernière démarche a été rendue possible grâce à un portail, permettant
la dissociation des tâches informatiques de l’entreprise.
Stratégies en cascade
Pour s’imprégner des différents aspects de la définition des priorités, une
autre méthode consiste à recourir à la cascade de stratégies. Avec une cascade,
vous pourrez analyser chaque domaine clé, comme la supériorité des coûts,
la différenciation et la qualité. La cascade peut s’appliquer à des domaines, à
des processus associés ou à des étapes dans la chaîne des valeurs. Si vous
considérez un processus associé comme l’objet de l’analyse, la question en
cascade pourra être : « comment garantir la supériorité des coûts dans le pro-
117
SOA for Profit
cessus de sécurisation des capacités fournies sur la base des prévisions ? ».
Des réponses sont apportées à ces questions pour tous les objets par domaine
stratégique. Nous obtiendrons ainsi un ensemble d’opportunités basé sur la
stratégie réellement suivie. Ces opportunités se situant à des niveaux très
différents, vous devrez les regrouper et les réinterpréter, puis les convertir en
des paramètres d’entrée utiles pour les plans de transformation.
Exemple d’atelier
Identifier les opportunités SOA
Cet exemple est un mini-projet que vous allez élaborer pour établir un plan de transformation SOA. En moins de trois semaines, vous obtiendrez une vue intéressante des
priorités et de l’approche en effectuant une série d’entretiens et en organisant un
atelier pour assurer la mise en phase de toutes les parties. Ici, le but de cette méthodologie visionnaire des processus est d’identifier et d’évaluer rapidement le potentiel
d’entreprise en fonction d’un développement informatique spécifique. Aujourd’hui, la
devise est « Ne vous fiez pas aux apparences et profitez du potentiel réel de la SOA ».
Comme l’informatique est à la fois une innovation guidée par l’activité et un élément
moteur de l’innovation d’entreprise, le public visé ici est l’équipe de direction et
d’autres responsables de secteurs clé, idéalement des groupes de 8 à 10 personnes.
Au cours du mini-projet, nous allons appliquer certaines des techniques traitées dans
ce chapitre.
La méthode est très rapide et donne, dans tous les cas, des résultats très intéressants
et utiles. On peut la considérer comme un processus rapide de reformulation. En trois
semaines et moyennant une participation d’un jour et demi par personne, vous obtiendrez :
• Des opportunités d’affaires SOA définies, classées par priorité et établies.
• Un consensus de gestion et une compréhension de la SOA et de son potentiel.
• Un consensus de gestion et la compréhension de tous les aspects de l’activité.
• De nouvelles approches de la stratégie d’entreprise, et peut-être la mise en place
des bases pour un changement de stratégie.
• Une trame de base permettant la réalisation de la première ébauche d’un plan
de transformation SOA de haut niveau.
La méthodologie comporte quatre parties :
1� Entretiens ciblés
2� Analyse et préparations d’atelier
3� Atelier
4� Documentation et suivi.
118
5 Repenser votre activité
1. Entretiens ciblés
Les entretiens ciblés donnent un aperçu précis de la stratégie, des plans et des attentes d’un groupe d’acteurs clé. Ils sont menés individuellement avec tous les participants. Dans chaque cas, vous utiliserez un modèle d’entretien bien préparé. La batterie de questions et d’exercices est destinée à passer au peigne fin les stratégies
d’entreprise et les opinions des individus, en adoptant plusieurs points de vue. Le
public ciblé est l’équipe de direction et d’autres acteurs clé, dans l’idéal 8 à 10 personnes. Le but est d’obtenir une vue générale de la stratégie et des priorités comme
trame de base d’un atelier. Le temps requis par entretien est de 2 heures.
Exemple d’un entretien type :
• Introduction : description des objectifs de haut niveau du plan de transformation
et regroupement des attentes individuelles.
• Quelles tendances observez-vous sur votre secteur ? Sont-elles perçues comme des
éléments porteurs ou des obstacles ?
• À plus long terme (au-delà de 5 ans), comment décririez-vous les objectifs et les
perspectives de l’entreprise ?
• Quels sont les principaux défis que votre société doit relever dans les 5 prochaines
années ?
• Quelles sont vos catégories de clientèle prioritaires ?
• Quels canaux de distribution utilisez-vous pour atteindre ces segments ?
• Quels sont les 5 changements majeurs auxquels vous aspirez pour vos principaux
clients ?
• Qui sont vos concurrents et pourquoi ?
• Quels sont vos atouts ? (trois exemples)
• Quelles sont vos principales opportunités ? (trois exemples)
• Discussion : étude d’une chaîne de valeur hypothétique avec propositions de changement.
• Discussion : étude du modèle de potentiels et identification des principaux flux
d’information et des points d’interaction humaine sur un plan individuel.
• Que pensez-vous du support informatique actuel ? Le jugez-vous satisfaisant ou
non ?
• Que pensez-vous des systèmes informatiques en termes de maturité, pour vousmême et pour l’entreprise en général ?
• Priorités : organisation d’une session de tri de cartes destinée à identifier et définir
les opportunités prioritaires. Dans l’idéal, les cartes doivent être identiques au
bloc du modèle de potentiels. Le participant doit choisir cinq cartes (fonctions) au
maximum qu’il juge prioritaires, puis les classer. Son choix donnera lieu à une
discussion, et sera consigné.
119
SOA for Profit
•
•
Connaissez-vous les applications informatiques utilisées par vos concurrents et
souhaiteriez-vous disposer d’une application particulière ?
Et enfin, avez-vous des conseils à donner pour notre travail à venir ?
2. Analyse et préparation de l’atelier
Le travail consiste à compiler les résultats des entretiens au sein d’un récapitulatif, à
établir un exemple commun de chaîne de valeur et de modèle de domaines/potentiels,
puis à regrouper les résultats communs pour le classement des priorités d’opportunités.
À partir des réflexions recueillies sur les meilleures pratiques, une recherche est menée
pour identifier et décrire les meilleures pratiques de l’entreprise. D’autres meilleures
pratiques SOA applicables à l’activité présente, connues ou identifiées par l’équipe
du formateur, seront également rassemblées et définies.
L’atelier doit être préparé avec minutie afin de prévenir tout dysfonctionnement en
cours de travail. Comme le temps alloué est court, les interruptions inattendues ne
seront guère souhaitées. Préparer l’atelier consiste à planifier les sessions de brainstorming, à établir des priorités et à identifier les éventuelles interférences à
l’avance.
3. L’atelier
L’atelier amorce les communications, établit un consensus et donne un aperçu commun des opportunités et de la voie à suivre. C’est une session d’une journée complète
où le travail de brainstorming a généralement lieu après le repas.
Exemple de l’ordre du jour d’un atelier :
• Présentation des résultats des entretiens : « votre vision commune » (présentation
par des discussions ouvertes, modérées).
• « Typologie des possibilités » : exemples de meilleures pratiques SOA. De préférence, pour aller en profondeur dans l’organisation : pratique mondiale, pratiques
du secteur et enfin segment industriel. Il est possible de commencer par une
explication pour démystifier et éluder toute question existante (par une présentation).
• Session de brainstorming : quelles sont vos opportunités de la SOA ? (brain­
storming modéré)
• Classement dans des zones d’opportunités (par la technique de modération).
• Classement des priorités à partir de la matrice Gain/Facilité (discussion/votes).
• S’il reste du temps : stratégie en cascade pour opportunités prioritaires (brainstorming structuré).
• S’il reste encore du temps : définition d’un plan d’action (discussion).
120
5 Repenser votre activité
4. Documentation et suivi
Pour finir, les participants doivent documenter et utiliser les résultats des entretiens de
l’atelier pour établir des modèles intégrables dans un plan de transformation SOA. Une
fois le rythme pris, il est nécessaire de bien le conserver pour la suite du voyage SOA.
5.8 Comment les modèles industriels vous aideront-ils ?
Pour étudier la valeur des modèles industriels et accélérer le processus,
demandez-vous quelles sont les spécificités de votre entreprise. Qu’est-ce qui
vous distingue de vos concurrents ? Et que veut dire « réajuster » ? Ne seraitce pas merveilleux de disposer, pour tous les « réajustements », d’un plan
simple et tout prêt qui détaille les services, les potentiels et les processus ? Et
peut-être aussi des solutions informatiques déjà toutes faites pour ces processus ? Bien sûr, il y a plusieurs façons d’y parvenir.
Des modèles industriels qui décrivent les éléments communs au sein d’un
secteur font leur apparition. De la même manière qu’un modèle de données
commun qui décrit produits et services, les modèles industriels détaillent
aujourd’hui les processus, les potentiels et les services. S’il existe déjà un
modèle pour le secteur dans lequel votre société intervient, vous pourrez
l’étudier ou participer à son élaboration ; cela vous facilitera le travail de
« réajustement » lors de la modélisation et de l’optimisation de votre activité.
Vous trouverez, par exemple, des cartographies de potentiels toutes faites. Le
concept CBM (Component Business Modelling) d’IBM est un bon support
pour cette ingénierie d’aller-retour (qui consiste à rattacher directement les
modèles à la production de logiciels). Il possède des liaisons directes avec un
éventail important de modèles de processus tout faits, rapidement exploitables comme solutions.
En revanche, il y peu de choses à attendre pour ce qui rend votre société
unique. Parfois, vous pourrez utiliser un modèle radicalement différent de la
plupart de vos concurrents. En effet, un modèle d’une autre industrie peut
aider. Mais en général, à chacun de définir son modèle.
La règle d’or pourrait être : réutilisez tout ce que vous pouvez sans renoncer
à vos avantages sur la concurrence. Et lorsque vous recherchez des éléments
réutilisables, ne vous tournez pas obligatoirement vers des modèles complets.
Vous pouvez aussi trouver des solutions spécifiques pour relever le défi de
121
SOA for Profit
l’architecture en silos par rapport à l’architecture partagée par exemple, ou
pour traiter un potentiel en particulier qui constitue un enjeu majeur pour
votre société.
5.9 Synthèse
Dans ce chapitre, nous vous avons présenté une nouvelle approche de votre
activité, une façon d’appréhender du haut vers le bas les domaines, les services et les potentiels associés à votre entreprise. Cette approche permet aussi
de repenser une organisation, en partant d’une entité fonctionnelle pour
aboutir à une architecture orientée services, plus facile à modifier et davantage centrée sur des paramètres qui vous distingueront de vos concurrents.
Nous avons démontré qu’il était assez simple de descendre jusqu’au niveau
des services en quelques étapes, avec un niveau de détail progressif. Nous
avons également décrit plusieurs aspects d’une transformation depuis l’organisation fonctionnelle avec son architecture orientée silos jusqu’à une
architecture orientée services. La transformation est le résultat final du processus de refonte d’une activité.
Pour terminer, nous vous avons donné quelques outils pratiques pour démarrer la discussion et définir les priorités de changement.
122
6 Une entreprise orientée services
6.1 Introduction
Dans le chapitre intitulé « Repenser votre activité », nous avons expliqué comment les entreprises traditionnellement organisées en lignes de métiers se trouvaient confrontées aux difficultés d’un monde actuel en pleine mutation. Ces
changements sont encore accélérés par les moyens de communication modernes
qui réduisent les distances. Dans ce contexte, on comprend mieux pourquoi la
philosophie et les objectifs SOA vous poussent à repenser votre activité.
Dans le présent chapitre, nous vous montrerons comment appliquer les principes SOA au sein de l’entreprise. Nous expliquerons comment les entités, les
équipes et les hommes peuvent eux aussi être perçus comme des services
pour aboutir à une organisation réellement dynamique. À cette fin, nous présenterons le concept de bus de services humains (Human Services Bus). Même
si nous n’attendons pas de vous que vous réorganisiez entièrement votre
entreprise pour vous engager pleinement dans cette démarche, les informations qui suivent vous aideront à repenser votre activité et à anticiper les
changements qui interviendront lorsque la SOA sera devenue le modèle d’architecture standard.
6.2 Un exemple
Imaginez que nous sommes dans les années 1980 et 1990 et que vous êtes l’un
des principaux opérateurs de téléphonie mobile du marché. Vous avez mis en
place un business model en vous fondant sur les attentes des premiers acheteurs de téléphones portables. Sur cette base, vous avez défini une infrastructure et une organisation dotée de toutes les business units nécessaires. Vous
disposez ainsi d’une société qui est en mesure de couvrir, le plus efficacement
possible, la totalité des besoins identifiés des utilisateurs initiaux. Le pays est
quadrillé par vos commutateurs et réseaux qui vous permettent de proposer
les meilleurs tarifs pour tous les appels réguliers passés de presque tous les
points du territoire. Vous vous êtes développé et êtes devenu le premier opérateur de téléphonie mobile.
123
SOA for Profit
Votre entreprise s’est structurée avec les entités requises, chaque entité possédant son propre département informatique chargé de concevoir les meilleures solutions possibles pour l’assister. Toutes les entités sont ainsi optimisées
et utilisent les solutions d’exploitation les plus performantes pour la réalisation de tâches spécifiques (facturation, entrée des factures clients ou opérations de commutation par exemple).
Or, au fil du temps, des concurrents commencent à arriver sur le marché. L’un
d’entre eux propose des contrats à tarif forfaitaire à ses clients s’ils appellent
des numéros spécifiques. Un autre concurrent se distingue par l’excellence
de ses services de centre d’appels qui permettent à la clientèle de demander
le contrat le mieux adapté suivant son historique. Pour faire face à ces nouvelles offres et rester compétitif, vous étudiez votre structure et découvrez
que toutes ces nouvelles offres vous obligent à repenser vos solutions informatiques. La structure naguère si performante se révèle brusquement un
poids pour la survie de votre entreprise.
Comme nous l’avons déjà mentionné, le concept SOA peut vous aider dans
cette démarche. Il propose des services bien définis pour des tâches nouvelles ou des processus modifiés en prenant les résultats de plusieurs services
de données des entités pour les combiner dans un nouveau service proposé
aux clients. Vous pouvez envisager la mise en place d’un service de simulation
de tarifs et de modèles d’utilisation par la clientèle à titre d’information. Jusqu’ici, une solution technique pourrait vous aider.
Mais maintenant, votre agent de centre d’appels doit être autorisé à faire
passer rapidement d’un tarif A à un tarif B le client qui appelle, simplement
en contournant plusieurs paramètres, en fait en établissant un nouveau
contrat entre votre société et le client. Et cela doit être possible immédiatement, sans interférence ni procédure complexe qui implique plusieurs lignes
de décision. Si le client souhaite un tarif forfaitaire pour une zone particulière,
il doit exister un moyen de faire appel à tous les services appropriés pour
satisfaire ce client et de présenter un ensemble complet de services. Le client
doit être localisé et facturé en fonction des nouvelles conditions tarifaires.
L’exemple montre clairement qu’après l’installation d’une solution basée sur
les services, le besoin d’une organisation adaptée se fait ressentir. Bien que la
SOA soit la plate-forme la plus flexible pour les systèmes informatiques, le défi
que l’entreprise doit relever est d’adapter sa structure afin d’exploiter à fond
le potentiel lié à l’orientation des services. Dans l’exemple évoqué, cela équi-
124
6 Une entreprise orientée services
vaut à responsabiliser l’individu et à proposer des règles de base pour l’utilisation de services qui puissent garantir aux clients la souplesse qu’ils exigent.
6.3 Une configuration dispersée mais bien cadrée
Les structures hiérarchiques centrées autour de lignes de métiers (les silos
d’une entreprise) ne sont plus assez efficaces pour garantir la réactivité
requise afin de répondre aux mutations constantes auxquelles l’entreprise
doit faire face.
En conséquence, adopter la vision SOA permet de migrer vers de nouveaux
modèles d’organisation destinés à la mise en place d’une entreprise orientée
services. Voici certaines des caractéristiques de ce type d’entreprise.
Les défis SOA pour l’organisation de l’entreprise
• Il est impératif de supprimer les silos.
• La flexibilité est obtenue par un regroupement autour des processus et des besoins
de l’entreprise.
• Une entreprise orientée services a besoin d’une organisation orientée services.
• La SOA amène l’entreprise à l’informatique et inversement.
• Les objectifs d’entreprise basés sur les demandes des clients déterminent les
actions à entreprendre.
• Un dialogue doit s’instaurer sur les services qui alignent l’entreprise avec l’informatique.
• La SOA aligne les stratégies de l’entreprise et celles de ses services informatiques.
Lorsque vous réorganisez l’entreprise pour rationaliser l’infrastructure orientée
services, la priorité est de supprimer les silos, c’est-à-dire de dépasser les limites traditionnelles des entités. Il s’avère que les gens aiment travailler de cette
manière : e-mails, portails collaboratifs et messageries instantanées permettent
à tous de partager des informations. Ces échanges d’informations peuvent revêtir un caractère ad hoc ou planifié, synchrone ou asynchrone : le travail peut
s’organiser aussi bien autour des besoins et des processus métiers.
Il est important que certains processus, comme ceux initiés par la demande
des clients, obéissent à des règles précises, qu’ils transitent par plusieurs
business units et donnent les résultats escomptés. Ces processus peuvent être
entièrement planifiés ou simplement amorcés en fonction de directives
125
SOA for Profit
convenues. Néanmoins, vous devez absolument éviter toute implication non
productive d’éléments non contributeurs, par exemple le fait de demander à
un directeur s’il est possible de faire appel à une autre unité ou encore le fait
pour la direction d’improviser des décisions à la va-vite lorsque l’employé
désigné refuse de prendre des responsabilités.
Les outils collaboratifs (e-mails, bases de données partagées, messageries instantanées, solutions VoIP intégrées, accès aux services informatiques et métiers)
peuvent être considérés comme une épine dorsale, ou plus précisément, un
ensemble d’outils de médiation conçus pour des personnes qui collaborent
entre elles. De la même façon, un bus de services d’entreprise sert de médiateur
au niveau technique. Enfin, les méthodes de travail visant à satisfaire les exigences des clients pourraient s’en voir modifiées, car il est désormais possible
d’échanger pour accomplir les tâches requises. Ce type de modèle innovant
d’organisation s’appelle « bus de services humains » [Bieberstein 2006].
6.4 Le bus de services humains (HSB)
Pour adapter sa structure, toute entreprise qui utilise un modèle comme le
HSB (bus de services humains) doit développer sa sémantique SOA traditionnelle et décomposer les structures organisationnelles existantes (en les combinant pour optimiser les avantages et limiter les restrictions).
6.4.1 Le bus d’orchestration et de collaboration (COB)
Dans son cœur, le HSB comporte un cadre de communication et de collaboration, c’est-à-dire un moteur informatique qui soutient sa structure logique.
De la même façon que le bus de services d’entreprise associe les services dans
un contexte SOA, le bus d’orchestration et de collaboration (COB, Collaboration and Orchestration Bus) associe les individus dans leur rôle au sein de
l’entreprise.
On peut ainsi imaginer une architecture de référence SOA peuplée d’individus et non de services programmés. Dans une entreprise, les employés, partenaires et clients sont à la fois demandeurs et fournisseurs de services.
Le COB fournit l’infrastructure informatique nécessaire pour faire connaître
de manière formelle les services d’équipe en proposant des outils de gestion
126
6 Une entreprise orientée services
des flux de travail destinés à soutenir les activités communes et la coordination au sein des services (et des équipes), suivre la réalisation des tâches et
anticiper les crises. Au niveau de chaque strate, les agents de service disposent d’outils spécifiques de planification et de conception afin d’identifier,
orchestrer et chorégraphier les services de niche depuis les strates inférieures. Des tableaux de bord exécutables et des outils d’information configurables fournissent en temps utile des clichés instantanés de paramètres métriques sur des flux de services et des données de productivité.
Employés
Les services sont virtualisés et les individus composant les équipes assurant
le service peuvent être géographiquement dispersés. Pour faciliter le travail
d’équipe, le COB propose également un portefeuille d’outils collaboratifs. Un
ensemble complet d’outils synchrones et asynchrones constituent l’arrièreplan de la messagerie du COB. Des systèmes comme les e-meetings avec
tableaux blancs électroniques, les messageries instantanées, les webcasts et
autres outils de communauté orientés tâches complètent les outils de communication synchrones existants (téléconférence par exemple). Avec l’avènement de Web 2.0 qui gagne actuellement du terrain dans l’entreprise,
d’autres outils seront bientôt disponibles.
Outils
collaboratifs
Outils d'équipe
Clients / Partenaires
Orchestration,
Création et
Suivi des services
Outils externes
pour clients
et partenariats
Services humains organisationnels
Services
d'équipe
Services
départementaux
Services
entité
Services
division
Services
groupe
Bus d'orchestration et de collaboration
(COB)
Outil répertoire de services
Outil répertoire d'actifs
Outil répertoire d'employés
ODOE et lieu de travail à la demande
Figure 6.1 : Bus d’orchestration et de collaboration utilisé comme noyau du HSB
La Figure 6.1 présente en détail l’organisation du COB. Les outils de classements en répertoires destinés à identifier les individus, les actifs et les services les mieux adaptés sont essentiels pour favoriser la collaboration au sein
du HSB de manière à répondre aux attentes des clients. Les tâches d’orchestration des services et de suivi reposent sur des outils appropriés qui aident
la direction à mettre en place les services identifiés et disponibles. Finalement, le résultat sera la fourniture du service demandé au client.
127
SOA for Profit
6.4.2 Définition de la structure de service
Vous pouvez vous contenter d’installer le COB, ou seulement certains de ses
composants comme les e-mails ou une base de données partagée, et laisser
aux employés le soin de l’utiliser. Cela peut marcher dans les petites ou
moyennes entreprises. Mais dans les grandes entreprises ou dans les unités
importantes, une structure organisationnelle s’impose, qui relève indubitablement de la gouvernance et requiert un certain degré de discipline.
Nous allons maintenant vous expliquer brièvement comment installer le bus
de services humains (HSB). Le service constitue l’entité logique centrale du
HSB. Les services recouvrent tout ce qui entre dans la réalisation d’une tâche
spécifique, comme la définition des objectifs, les résultats tactiques ou la mise
en place d’une stratégie. Les services peuvent également être regroupés en
structures plus importantes et complexes.
Services de
groupe 1
Centrés sur
la mission
et les objectifs
Services de
division 1
Centrés
sur la
stratégie
Services
d’entité 1
Centrés sur
la mission
tactique
Services
départementaux 1
Centrés sur
la définition
des objectifs
Services
d’équipe 1
Services de
groupe
N
Services de
division
N
Services
d’entité
N
Services
départementaux
N
Orientés
Services
tâches
d’équipe 2 et activités
Services
d’équipe N
Figure 6.2 : Bus de services humains partie intégrante
du réseau opérationnel
128
6 Une entreprise orientée services
La Figure 6.2 illustre les différentes strates de services d’un HSB et leur raison d’être. De plus, pour optimiser les services et rationaliser les aspects
opérationnels, des agents de service doivent être désignés. Ces agents sont
des individus chargés de la surveillance, de la médiation ou de la chorégraphie des services. Leurs rôles et leurs responsabilités varient en fonction de
la strate et restent essentiels pour le HSB.
Services d’équipe
Ce sont les services les plus importants du HSB. Ils sont clairement définis
pour la réalisation de tâches et d’activités qui entrent dans les compétences
clés de l’entreprise. Les compétences des services d’équipe, comme le « test
fonctionnel du composant A dans le produit XYZ », le « benchmarking des
performances d’accès aux données sur le marché de la vente au détail », et le
« support client numéro un pour le composant B dans le produit XYZ », sont
pointues et précises. L’agent de service de cette strate est un directeur qui
joue le rôle de « médiateur » et veille à ce que le service soit opérationnel et
conforme aux obligations contractuelles. Son but est d’optimiser les liens avec
le moteur collaboratif, d’identifier les problèmes au quotidien et de gérer
régulièrement la motivation et l’éthique de l’équipe.
Services départementaux
Les services d’équipe sont regroupés au niveau départemental pour la réalisation des objectifs clés de l’entreprise. Le but est de créer des services départementaux comme le « test du composant A dans le produit XYZ », le « benchmarking de performances sur le marché de la vente au détail », et le « support
client sur le composant B dans le produit XYZ ». Les senior managers sont les
chorégraphes du service de niveau un. Ils doivent cerner les objectifs d’entreprise qui leur ont été attribués. À cette fin, ils créent un flux de travail basé sur
les services existants et s’assurent que les liaisons entre les flux sont rationalisées par des contacts avec les directeurs des services d’équipe.
Services d’entité
Ces services sont constitués en chorégraphiant les services départementaux
pour la conduite des tâches tactiques de l’entreprise. Citons par exemple les
« tests du produit XYZ », le « benchmarking des performances d’industrie », et
le « support client du produit XYZ ». Les services de business unit peuvent
aussi compléter l’orchestration des services départementaux en encourageant
directement les services d’équipe à satisfaire certaines de leurs exigences fondamentales. Il faut des talents d’encadrement pour concevoir ces services chargés d’exécuter et de proposer les éléments tactiques et de gérer les résultats
129
SOA for Profit
clés de pertes et profits. Un directeur est responsable de la chorégraphie des
services départementaux et des services d’équipe conformément aux exigences
requises. Il collabore avec les agents de service des strates inférieures afin
d’évaluer les services dont a besoin son unité. Il localise les goulots d’étranglement des processus, reformule les caractéristiques des services si nécessaire,
élimine les redondances et définit de nouveaux services « émergents ».
Services de division
Les services de business unit doivent être modulés en fonction des objectifs
stratégiques de l’entreprise. Les services de division peuvent être la « gestion
du produit XYZ », la « gestion de solutions industrielles », les « relations clients »,
etc. Ils ont à leur disposition les services d’équipe, les services départementaux
et les services de division et peuvent les amener à leur niveau de granularité
optimale. Les senior managers, comme les vice-présidents et les directeurs
généraux, doivent réaliser les objectifs stratégiques en orchestrant les services
de division et en canalisant les fonds de la manière la mieux adaptée.
Services de groupe
Ces services sont entièrement dédiés à la conduite de la mission et des objectifs de l’entreprise. Ils définissent les stratégies et les gèrent en orchestrant
les services de division comme les « services de portefeuilles logiciels », les
« services de solutions industrielles », etc. Les vice-présidents seniors (SVP,
Senior Vice President) travaillent en collaboration avec le CEO et son équipe
pour définir les objectifs périodiques et la stratégie générale de l’entreprise.
Chaque SVP suit les performances et les résultats de ses services de division
et d’entité et établit des directives à cet effet.
La taille des équipes qui constituent les services dépend de l’activité, de la
portée des missions et de l’importance des services. Certains services très
sollicités (par exemple les services administratifs/le secrétariat) peuvent être
redondants et assistés d’une multitude d’équipes. La densité requise d’un
service particulier sera déterminée en fonction des besoins de l’entreprise et
des coûts.
Définir des services avec des activités différenciées et des résultats distincts
facilitera la démarche de rationalisation d’une grande structure, et permettra
de supprimer les équipes redondantes et de réduire les dépenses. La tâche
de différenciation des services en sera facilitée, car il sera plus aisé d’éliminer
les services moins stratégiques et de créer de nouveaux services avec des
besoins « émergents ». Grâce à cette souplesse, l’entreprise pourra faire
130
6 Une entreprise orientée services
preuve d’une grande réactivité face aux nouvelles opportunités et aux menaces de la concurrence. Les services basés sur l’informatique et sur les individus à la fois seront externalisés de la même manière et le contrat de services
défini par l’interface fera abstraction de l’origine du service.
6.5 L’importance du Web 2.0 pour une entreprise orientée services
La souplesse d’intervention de la part de services informatiques flexibles exige une
transformation de l’activité de l’entreprise par :
• Une réorganisation de l’environnement informatique pour une plus grande flexibilité.
• Une réorganisation des structures d’entreprise jusqu’au niveau de souplesse
demandé.
• La méthode permettant de rendre une « entreprise agile » opérationnelle.
• Le fait que les outils et le service informatique constituent simplement des moyens,
et non pas des éléments moteurs.
• L’utilisation des besoins et des objectifs d’entreprise comme éléments moteurs
fondamentaux.
• L’évaluation de la réussite service par service.
• Une organisation répondant aux besoins des professionnels habilités.
• L’établissement de directives et de structures organisationnelles destinées à une
entreprise orientée services.
Comme nous l’avons résumé dans l’encadré ci-dessus, les outils de création
des services ou des processus métiers constitués de services bien définis et
orchestrés sont proposés aux experts pour leur utilisation et réutilisation.
Outre les services planifiés, pré-planifiés et préparés, il existe un nombre
accru d’outils destinés aux professionnels pour modifier et concevoir ad hoc
des services et des outils. Ces outils sont compatibles Web 2.0.
La communication asynchrone est assurée par des équipes spécialisées, des
bases de données de projet, des portails et des forums d’équipe interactifs
ainsi que par des e-mails. De plus, Web 2.0 propose des outils à la portée de
chaque personne engagée dans le modèle HSB qui souhaite personnaliser
son espace de travail et créer des outils ad hoc utiles. Le Tableau 6.1 fournit
une vue d’ensemble des diverses technologies proposées sous Web 2.0.
131
SOA for Profit
Technologies
Définition des tâches et usages
Réseaux sociaux
Technologie destinée à favoriser les contacts personnalisés
RSS
Standard pour utilisateurs souhaitant collecter et lire des
contenus
Logiciel open source
Logiciel public
Blogs
Journaux en ligne contenant des textes, images et autres
supports électroniques
Moteurs de recherche
Moteurs disponibles pour la recherche de contenus Web
Portails de consultation Portails de consultation de services ou produits
utilisateur
Partage de fichiers P2P
Partage de fichiers média entre des communautés en ligne
eCommerce C2C
Plate-forme de vente de produits en ligne
Sites comparatifs de
prix
Sites permettant aux consommateurs de comparer les prix
des produits et des services proposés en ligne
Podcasts
Vidéo ou audio en ligne à télécharger pour un usage répété
Wikis et autres outils
collaboratifs
Publication partagée sur Internet
Tagging
Métadonnées affectées à des éléments sur Internet
Tableau 6.1 : Technologies Web 2.0
Chaque employé au sein de l’entreprise peut utiliser la plupart des technologies du Tableau 6.1 comme de véritables services. Néanmoins, suivant le
savoir-faire des uns et des autres, les outils autogénérés deviennent plus ou
moins sophistiqués et sont proposés à leurs homologues. À un certain niveau,
un marché spécifique peut même se développer au sein d’une entreprise, ce
qui signifie que des solutions logicielles sont proposées et déployées, indépendamment du service informatique central.
La tâche consiste désormais à proposer la plate-forme adaptée et à suivre les
actions continues sur le net afin d’éviter toute action abusive ou illicite.
Comme le rôle d’un directeur est de s’impliquer de plus en plus dans la définition et la surveillance des règles, le système informatique central devient
un fournisseur d’infrastructures, de services informatiques et une unité de
mesure. Reportez-vous au chapitre 7 pour plus d’informations sur les rôles et
implications des individus à ce sujet. Pour garantir une approche flexible et
souple au sein de l’entreprise, il est souhaitable de laisser cette plate-forme
se développer librement. Le service informatique central doit simplement
surveiller l’apparition d’effets secondaires indésirables et apporter un conseil.
Toute tentative de réglementation stricte et d’application de processus de
132
6 Une entreprise orientée services
validation formelle réduira à néant les avantages. Par ailleurs, les collaborateurs les plus jeunes, qui ont grandi avec l’informatique, seront déçus de ne
pas pouvoir adapter leurs outils en fonction de leurs besoins immédiats.
6.6 Synthèse
Prenez les concepts SOA et utilisez-les pour façonner les interactions entre
les collaborateurs, les équipes et les unités ; vous assisterez à l’émergence
d’une organisation d’un type résolument nouveau : flexible, auto-optimisante
et potentiellement ouverte aux interactions au-delà des limites organisationnelles. Vous verrez ainsi comment les services combinés à certains outils technologiques de communication peuvent aboutir à une méthode de travail radicalement nouvelle.
Pour les entreprises plus importantes, ce nouveau modèle nécessite aussi un
encadrement et une structure, qu’il s’agisse de référentiels ou d’éléments
organisationnels (définitions de nouveaux rôles et tâches, unités possédant le
pouvoir de décision et l’autorité, législation de base ou règles d’éthique, etc.).
Même si votre entreprise n’est pas prête pour un tel changement, il peut être
intéressant de déterminer si de nouveaux venus peuvent aisément entrer sur
le marché en utilisant ce modèle. Et dans l’affirmative, en quoi votre position
sur le marché en serait-elle affectée ?
Néanmoins, l’organisation seule ne garantit pas le succès. Une entreprise
orientée services a également besoin de collaborateurs dotés de rôles et de
comportements orientés services, adaptés pour animer une telle structure,
comme nous le verrons au chapitre 7.
133
7 Des collaborateurs orientés services
7.1 Introduction
Comme nous l’avons expliqué dans notre chapitre sur l’orientation services
et, au début, dans les réflexions fondamentales sur la transformation de l’activité et la gestion des changements, vous pouvez utiliser certains éléments
organisationnels et opérationnels pour obtenir les résultats escomptés. Néanmoins, les collaborateurs sont et resteront le facteur clé du fonctionnement
de l’entreprise. Ils constituent aussi l’actif le plus important pour relever les
nouveaux défis auxquels chaque organisation se trouve confrontée. L’adaptation d’une architecture orientée services nécessite des collaborateurs orientés services.
Dans ce chapitre, nous allons décrire deux dimensions essentielles de ces
collaborateurs orientés services : leur rôle dans une entreprise orientée services et les implications d’un tel engagement pour les collaborateurs, leurs
compétences, leurs profils personnels et leur comportement. Ces deux éléments se révéleront essentiels pour le succès de l’entreprise.
Les mutations opérées dans l’économie mondiale nécessitent, de la part des
entreprises concurrentes, la plus grande souplesse d’adaptation possible.
C’est la raison pour laquelle les collaborateurs au sein d’une entreprise doivent faire preuve d’un degré de flexibilité plus important que jamais et
s’orienter vers les exigences des clients et du marché.
7.2 Rôles SOA
Les rôles décrits dans ce chapitre sont tirés d’exemples réels. Une personne
peut assurer un seul ou plusieurs rôles et un groupe de personnes peuvent
remplir conjointement une fonction spécifique ; tout dépend de la situation
de l’entreprise. Lorsque nous parlons de rôles, nous voulons mettre en valeur
les tâches et les responsabilités propres à l’organisation orientée services de
l’entreprise.
135
SOA for Profit
Comme l’ont démontré Peter Weill et Jeanne W. Ross dans leur travail sur la
gouvernance informatique, les moyens de parvenir à la meilleure organisation
de l’entreprise sont multiples. En effet, il existe plusieurs combinaisons de
droits et de règles relatifs à la prise de décision, d’institutions, d’équipes, de
choix des décideurs et d’autres critères qui déterminent le succès de la gouvernance de l’entreprise.
Nous avons déjà évoqué la nécessité d’un lien plus étroit entre l’entreprise et
son système d’information, qui représente l’un des facteurs majeurs de réussite de la mise en œuvre d’une approche SOA. Par ailleurs, comme plusieurs
analystes l’ont supposé, il est impératif que l’informatique s’adapte à toute
ligne de métiers au sein de l’entreprise. L’informatique n’est donc plus perçue
comme une simple unité exécutante qui ne représente qu’un coût. Sa contribution dans la valeur de l’entreprise en général, ainsi que dans des cas d’activité concrets, est maintenant reconnue.
Avec un plus grand nombre de services et une infrastructure SOA plus étoffée
pour concevoir rapidement de nouvelles solutions, l’informatique sera moins
technique et davantage orientée vers les connaissances métier. L’informatique
deviendra un véritable partenaire de l’entreprise. Fini le temps où les entités
donnaient leurs instructions pour que les départements informatiques puissent résoudre les problèmes, fournir des solutions et assurer la maintenance
au bénéfice de l’activité. Un authentique dialogue va s’instaurer. Si dans le
passé, la solution finale ne reflétait pas vraiment les besoins de l’entreprise
ou que les services informatiques prenaient trop de temps à proposer une
solution adaptée, les business units prenaient la liberté de s’adresser au marché pour trouver les meilleures solutions dont elles faisaient l’acquisition ;
elles demandaient ensuite à leurs départements informatiques de les intégrer
et d’en assurer la maintenance, sans impliquer ces derniers dans la décision
d’achat.
Le résultat est visible dans presque toutes les entreprises actuelles, où plus
de 80 % des efforts déployés restent encore consacrés à l’intégration et à la
maintenance d’une multitude de solutions ponctuelles, chacune d’entre-elles
étant conçue pour couvrir non seulement un domaine, mais tout l’environnement afin de devenir une solution à part entière. Bien sûr, les fournisseurs
de logiciels et intégrateurs de solutions ne pensaient pas en termes de réutilisation et d’intégration lorsqu’ils concevaient leurs solutions, comme cela
est le cas désormais avec la SOA. Il existe un patrimoine important – même
136
7 Des collaborateurs orientés services
s’il n’a que quelques années – qui nécessite une intégration. Maintenir des
solutions conçues pour une multitude d’environnements et de plates-formes
signifie aussi que les départements informatiques doivent soit disposer en
interne de compétences étendues, soit recourir à des fournisseurs compétents.
Dans ce nouveau contexte de rapprochement de l’informatique avec l’entreprise, le rôle de l’architecte d’entreprise devient primordial.
7.2.1 L’importance de l’architecte d’entreprise comme médiateur entre métier
et service informatique
Le profil des compétences d’une personne assumant le rôle d’architecte d’entreprise médiateur est certainement plus étendu que celui, par exemple, d’un
développeur de logiciels ou d’un propriétaire de processus métiers dans une
entité donnée. Néanmoins, les connaissances et l’expérience de l’architecte
ne sont pas aussi pointues que celles de ces experts.
La Figure 7.1 illustre les domaines clés d’expertise et la valeur ajoutée de
l’architecte au sein d’une entreprise, son rôle étant d’assurer un équilibre des
objectifs. L’entreprise a pour principales exigences d’être aussi flexible que
possible sur le marché, d’accroître ses recettes et de veiller au respect du
nombre grandissant de règles et réglementations imposées par les entités
politiques et industrielles. De même, l’informatique doit suivre certains standards, soit des standards volontairement mis en place en interne, à l’instar de
règles valables pour l’ensemble de l’entreprise, soit des standards développés
par l’industrie informatique, par des groupes indépendants (open source) ou
par des fournisseurs. Parallèlement, l’informatique doit se plier aux exigences
imposées par les solutions souhaitées pour les consommateurs au sein de
l’entreprise.
Compte tenu du cas particulier de l’infrastructure SOA, l’informatique sera
un instrument de mesure de l’activité de l’entreprise (par une surveillance
des indicateurs de performance clés), mais aussi de son propre service (par
exemple, avec des données sur les performances pour lesquelles les contrats
de niveau de service ont été établis).
137
SOA for Profit
Accélérer mise
sur le marché
Augmenter
recettes
Conformité
de l'activité
Objectifs
métiers
Fonction
(définition services)
Aligner objectifs métiers
et informatique
Architecture d'entreprise
Architecture
de référence
Sécurité et
conformité SI
Performance et
qualité (KPI)
Objectifs SI
Gouvernance
Feuille de route
Figure 7.1 : L’architecte d’entreprise, médiateur
entre le métier et le service informatique
Dans une entreprise orientée services, l’architecte doit connaître le contexte
et disposer d’une bonne compréhension des problèmes liés à la fois au métier
et à l’informatique pour pouvoir jouer le rôle de médiateur entre des priorités
souvent contradictoires. Les tâches et responsabilités spécifiques sont traitées
en créant une architecture de référence, véritable feuille de route vers le
concept de SOA adaptée à l’entreprise et à ses entités, et enfin en appliquant
le suivi de la gouvernance, comme nous l’avons évoqué dans l’un des précédents chapitres.
Le fait que l’architecte d’entreprise possède ou non des connaissances en
informatique, dans l’organisation COO ou dans une entité spécifique, ne
constitue pas une priorité. L’acceptation du rôle de ce collaborateur (ou dans
le cas d’une plus grande entreprise, de l’équipe d’architectes) par les deux
parties est beaucoup plus importante. En général, cette acceptation ne s’impose pas par décret. Elle s’acquiert en faisant preuve de compétences et de
talents éprouvés. Des qualités telles que la diplomatie et le leadership sont
particulièrement indispensables.
Une des tâches qui entrent dans les attributions d’un architecte est l’établissement de la feuille de route SOA de l’entreprise, par exemple, à partir du
modèle de maturité décrit au chapitre 8. La fonction de l’architecte est de
tracer la feuille de route et de coordonner les travaux qui s’imposent. Cette
démarche nécessite une interaction et des talents de diplomate pour jouer le
rôle de médiateur du fait d’intérêts souvent contradictoires ou divergents
entre métier et informatique.
138
7 Des collaborateurs orientés services
Comme nous l’avons déjà expliqué, l’architecte occupe une position centrale
entre les deux camps : les spécialistes informatiques d’une part et le métier
lui-même. Généralement, il guide le centre d’excellence SOA ou toutes les
autres entités de gouvernance chargées du voyage SOA. Mais il exerce également une multitude de rôles particuliers décrits dans les sections suivantes.
7.2.2 Autres rôles clés dans le cadre de l’approche SOA
Parmi les autres rôles clés qui comptent dans une entreprise, nous évoquons
les plus fréquents. Comme nous l’avons déjà expliqué, un rôle peut être assuré
par une ou plusieurs personnes. Une seule personne peut également remplir
plusieurs rôles. Cela dépend essentiellement de la taille de l’entreprise.
Le champion du service métiers
Le champion du service métiers (BSC, Business Service Champion) est l’élément central dans l’évolution de l’entreprise vers une architecture orientée
services ; il apporte au programme une compréhension approfondie des
métiers et de l’informatique. Le rôle doit être rempli par une personne très
respectée par les deux camps. Le BSC occupera une fonction au sein du
comité CoE (centre d’excellence) SOA, normalement mis en place comme un
élément clé pour l’organisation de la gouvernance SOA. Outre les responsables informatiques identifiés (architecte d’entreprise, BSC et autres professionnels confirmés suivant la taille de l’entreprise), chaque ligne de métiers
principale doit être « virtuellement » représentée au sein de ce comité par des
délégués habilités.
Comme nous l’avons souligné, le rôle de BSC de l’architecte d’entreprise
nécessite une excellente compréhension des capacités du processus métiers
et de l’informatique. Néanmoins, la fonction principale est de traiter les
problèmes liés aux processus métiers pour encadrer la planification des
services et des solutions. Une personne occupant cette fonction doit posséder la crédibilité requise pour identifier les problèmes liés à ces processus
et guider la planification voulue suivant les changements informatiques et
métier dans un domaine particulier.
De plus, il lui est demandé de bénéficier d’une excellente compréhension des
concepts SOA et de modélisation métiers, et de comprendre les mesures de
conformité et le modèle de gouvernance d’entreprise. La gestion des relations
139
SOA for Profit
et des attentes du CoE SOA fait partie des tâches dont le but est d’évaluer
précisément la portée des efforts du service. Enfin, le recours aux meilleures
pratiques du secteur complète l’expertise du BSC.
Dans ce rôle, les solutions sont développées et doivent être vendues aux
métiers et au service informatique de façon équilibrée. Comme c’est le cas
pour tous les membres du comité CoE, il n’est certainement pas aisé de trouver un juste milieu, dans ce contexte, entre les améliorations métiers à court
terme et une transformation stratégique à plus long terme. Cela est possible
en associant les visions relatives aux métiers et celles s’appliquant à l’architecture informatique, c’est-à-dire en revenant au lien fondamentalement
étroit entre ces deux entités, un lien dont nous avons déjà supposé l’existence
et qui constitue la base de toute SOA.
Le responsable du registre de services
Le responsable du registre de services est le gardien des métadonnées du
service de l’entreprise, son rôle étant de promouvoir les référentiels de réutilisation déjà en place. Ce responsable complète les référentiels d’actifs avec
des métadonnées appropriées et des opportunités de recherche. Il aide également à la création et facilite la mise en œuvre de la discipline nécessaire
pour peupler le référentiel. Afin d’éviter toute création de services redondants, le responsable demande aux équipes de projet de parcourir le référentiel avant d’entamer toute tâche de création/développement.
Toute personne qui remplit ce rôle doit bien maîtriser les concepts SOA,
notamment les anciennes technologies SOA, et être formé au développement
des procédures d’utilisation des actifs de services au regard de la SOA. Elle
doit également connaître sur le bout des doigts les concepts et les architectures de métadonnées et de recherche. Par ailleurs, pour remplir pleinement
cette fonction, le collaborateur ou l’équipe doit déjà posséder une expérience
dans la mise en œuvre des processus de contrôle des référentiels en se
concentrant sur les composants et les services réutilisables.
Cette personne doit aussi mettre en place et suivre les outils des référentiels
de services et leurs interfaces d’accès et assister toutes les parties concernées
en matière de processus d’identification des services. Son rôle consiste également à dégager un consensus autour de la publication des services en vue
d’établir les stratégies et les standards d’entreprise tout en s’engageant dans
la mise en place des stratégies et standards associés à la publication des services dans le référentiel.
140
7 Des collaborateurs orientés services
Dans cette fonction, le responsable soutient les autres membres du CoE et
aide à promouvoir la communication entre fournisseurs et consommateurs
de services. Par rapport aux incitatifs ou autres moyens de gouvernance déjà
mentionnés, cette personne peut être contrainte de contrôler l’utilisation et
la réutilisation des services.
Qu’elles soient assumées par trois collaborateurs différents, par une équipe
plus importante ou par une seule et même personne au sein de l’entreprise,
ces trois fonctions (architecte d’entreprise, champion des services d’entreprise et le responsable du registre de services) constituent le noyau de toute
transition réussie vers une entreprise orientée services.
Nous allons ajouter ci-après quelques fonctions, ou plus précisément quelques tâches identifiées pendant la mise en place et le fonctionnement d’un
atelier informatique SOA. Ces fonctions doivent coopérer très étroitement et
utiliser les outils et les moyens collaboratifs les plus récents, notamment le
référentiel de services.
L’analyste d’entreprise
L’analyste d’entreprise regroupe les exigences fonctionnelles des utilisateurs
et donne à l’équipe une connaissance du domaine. Il doit connaître le langage
de l’entreprise et posséder les connaissances spécifiques du secteur et du
domaine. Dans une approche SOA, l’analyste doit utiliser les méthodologies
présentées au chapitre « Repenser votre activité ».
Le développeur de services
Le développeur de services crée et teste la mise en œuvre des logiciels. Avec
la SOA, ce rôle ne change guère ; toutefois, le code doit être écrit dans les
programmes SOA sous forme de services, d’où l’appellation développeur de
services.
Le spécialiste sécurité
Le spécialiste sécurité est responsable de la définition des directives (stratégies) de sécurité et de la mise en œuvre des moyens de sécurité associés. Les
directives sont conformes aux standards du secteur dans la mesure où elles
reflètent la stratégie validée de l’entreprise en relation avec les partenaires
commerciaux. Ainsi, dans le secteur pharmaceutique par exemple, cela revient
à agir au sein d’une chaîne d’approvisionnement en tant que fournisseurs ou
partenaires de développement.
141
SOA for Profit
L’administrateur système et base de données
Ce responsable assure l’installation et la maintenance continue de l’infrastructure technique : matériel, systèmes d’exploitation, bases de données et
middleware. Certains aspects de l’intégration des informations sous SOA donnent encore plus de poids à cette fonction par rapport aux administrateurs
traditionnels de bases de données. L’administrateur doit disposer de compétences qui permettent le développement, la gestion et la maintenance des
services d’information préconisés dans le contexte de l’architecture de référence SOA.
Le déployeur de services
Le déployeur de services prend en charge les éléments de développement et
les installe dans l’environnement exécutable voulu.
Le testeur de l’intégration des services
Le testeur est responsable des différentes étapes de test standard comme les
tests d’intégration, de chargement et de validation. Il définit également les cas
à vérifier pour les tests d’interopérabilité et de conformité des services. Son
rôle est aligné sur celui de l’architecte et des responsables de la gouvernance,
comme préalablement décrit. C’est un rôle d’assurance qualité.
Le façonneur d’outils
Le façonneur d’outils est responsable de la conception et de la mise en œuvre
des scripts spécifiques au projet, des générateurs et d’autres services nécessaires dans le cadre de la SOA.
Son rôle peut diminuer à mesure qu’apparaissent sur le marché des outils de
développement de plus en plus sophistiqués. Néanmoins, il est toujours judicieux de disposer au sein de l’entreprise, d’une personne qui sait modifier et
paramétrer des outils en fonction des besoins des utilisateurs, des développeurs et des consommateurs. Cette personne peut même devenir un
conseiller, notamment par rapport à Web 2.0, les utilisateurs étant généralement amenés à modifier leur espace de travail en fonction de leurs tâches
quotidiennes.
L’animateur des transferts de compétences
Ce rôle donne accès à des experts du domaine et à des instructeurs techniques qui apportent leurs connaissances pointues concernant la SOA et dans
la plupart des cas, les services Web et les actifs de mise en œuvre. En associant
des cas pratiques d’utilisation apparus au fil des exigences, ce rôle peut faci-
142
7 Des collaborateurs orientés services
lement être assuré par des « customer proxies », qui représentent des demandes de services individuelles dans la SOA. Une fonction caractéristique de cet
animateur est d’apporter une assistance au responsable du registre des services. Ce rôle peut également faire partie intégrante du travail du responsable
du registre, suivant la taille des équipes.
Le responsable projet SOA
Ce rôle est une évolution du responsable projet traditionnel. Le responsable
projet SOA ne doit pas se contenter de planifier des cycles de fourniture
beaucoup plus courts. Il doit également définir de nouveaux modèles de
validation. Le responsable projet SOA doit collaborer avec les fournisseurs
de service afin d’établir des contrats de niveau de service appropriés et de
déterminer l’usage des ressources. L’importance de ce rôle grandit avec
l’utilisation accrue de services regroupés (ceux composés d’autres services).
L’administrateur système SOA
Outre la gestion et la surveillance de l’infrastructure de plate-forme, l’administrateur système gère également les contrats d’entreprise et de niveau de
service dans le contexte SOA. Très souvent, il assiste le responsable du registre de services évoqué ci-dessus. Néanmoins, l’administrateur système SOA
occupe un poste administratif, non proactif.
Le concepteur de flux de processus
Le concepteur de flux de processus est moins un expert de l’intégration qu’un
spécialiste en charge de la recherche de possibilités explicites et déclaratives
d’orchestration de services (agrégation, composition). Le concepteur se
concentre sur les flux techniques correspondant à des processus métiers particuliers. Son importance s’accroît en raison du standard BPEL et du nombre
croissant de fournisseurs d’outils de modélisation des processus métiers qui
assurent l’interface entre la création des processus métiers et les processus
exécutables.
Comme le nombre de services de base proposé est supérieur au nombre de
services combinables dans les domaines d’activité correspondants, l’automatisation des flux augmente et avec elle, par conséquent, la responsabilité du
concepteur de flux de processus. La SOA permet une mise en œuvre plus
rapide des processus métiers en mutation adaptés aux situations changeantes.
143
SOA for Profit
Le testeur d’interopérabilité
Le testeur d’interopérabilité doit s’assurer de la bonne interopérabilité de
toute mise en œuvre développée par les demandeurs et fournisseurs. Une
autre activité essentielle consiste à vérifier la conformité de l’interopérabilité
des services Web (WS-I) et la conformité aux standards industriels.
L’administrateur registre
L’administrateur registre détermine le mode de personnalisation et de peuplement d’un modèle générique de données de registre. En général, c’est un
rôle optionnel. Il dépend également du standard choisi ou de l’existence éventuelle d’un autre modèle de données propriétaires au sein de l’entreprise.
Dans ce cas, une autre fonction similaire, souvent partie intégrante de l’entité
chargée de la gouvernance informatique, pourra intervenir en tant qu’administrateur système SOA ou assumer le rôle de responsable registre.
7.3 L’impact sur les collaborateurs
Avec la SOA, ce ne sont pas seulement les compétences qui changent ou qui sont
redéfinies ; d’autres paramètres ont un impact certain sur les attitudes, les talents
et les comportements personnels au sein d’une entreprise orientée services. La
compréhension des services et des composants de ces services représente l’élément fondamental d’une approche SOA, les collaborateurs au sein de l’entreprise devenant des consommateurs et des fournisseurs de services, comme nous
l’avons évoqué dans le chapitre sur l’organisation orientée services.
Pour profiter pleinement d’un modèle de services SOA flottant, chaque professionnel se voit attribué davantage de droits de décision et de pouvoir, ce
qui lui permet d’intervenir sans autorisation ni instruction détaillée de la
direction ; l’adhésion à l’ensemble des règles et réglementations suffit. Cela
signifie que l’entreprise dans sa globalité devient plus souple et peut réagir
plus rapidement aux demandes des clients.
7.3.1 Le professionnel orienté services
Pour les collaborateurs de l’entreprise, cela signifie également plus de responsabilités, une plus grande exposition et moins d’excuses du type : « on m’a dit
de faire ça » ou « dans ce cas, la réglementation dit que… ». Comme la production industrielle s’est largement automatisée, nous nous trouvons confrontés à
144
7 Des collaborateurs orientés services
une période d’automatisation des processus métiers où toutes les procédures
standards itératives sont programmées pour être exécutées par l’informatique.
De même, l’interaction humaine est devenue un élément annexe dans l’industrie manufacturière. Actuellement, l’homme fournit des paramètres d’entrée,
relève les résultats et assure la surveillance des processus.
De nos jours, les technologies avancées qui favorisent un déroulement chorégraphié des services ou des composants métiers permettent une définition
plus flexible de ces processus métiers. Pour autant, l’individu doit-il devenir
une unité programmée ? Certainement pas ! La tendance à long terme dans
le secteur manufacturier démontre que l’homme joue un rôle d’initiateur, de
surveillant et de contrôleur pour des activités à la fois simples et relativement
complexes, les travaux répétitifs étant assurés par les machines.
De la même façon qu’avec les machines, des tâches administratives et un nombre grandissant de services ont été automatisés pour faciliter le travail de certaines entités : la force de vente qui dispose directement sur le terrain d’informations concernant les clients et leur situation financière, les experts
comptables spécialisés en fiscalité qui accèdent à des règles (rapidement obsolètes) formulées de manière intelligente, les « communicants » qui peuvent
présenter des offres adaptées à chaque client, et bien d’autres encore.
Souvent, les tâches automatisées doivent changer brusquement, tout en présentant toujours une interface familière aux utilisateurs du système. La fonction fondamentale de la SOA que nous avons décrite – à savoir la séparation
des domaines illustrée dans l’architecture de référence SOA – autorise
l’échange de certains services des applications métiers (par exemple, une
nouvelle formule pour calculer les taux d’intérêt ou les impôts dus) ou même,
la refonte intégrale d’un processus métiers, sans aucune modification de l’interface utilisateur ou de la structure de la base de données ou encore de toute
application patrimoniale intégrée, lorsqu’il n’existe pas de réel besoin.
Les collaborateurs apprendront en temps utile à obtenir des informations ou à
utiliser à bon escient des services d’information ad hoc pour leurs besoins immédiats. S’inscrire dans une structure organisationnelle telle que le bus de services
humains nécessitera un surcroît de dynamisme de la part des personnes impliquées. En revanche, l’expérience commune acquise avec Internet nous a préparés à cet environnement car nous sommes tous habitués à rechercher en ligne
des multitudes d’informations, de produits et de contacts. Même les générations
à venir adopteront cette démarche naturellement, sans aucune restriction.
145
SOA for Profit
Les aspects de la vie privée, du contrôle d’accès et des thèmes stratégiques
associés feront certainement l’objet de nouvelles discussions à la lumière des
marchés mondiaux et de la population active à l’échelle internationale.
Récemment, des syndicats ont commencé à revoir leurs positions et à se
regrouper au sein d’organisations internationales car un nombre croissant
d’entreprises déploie leurs activités à l’échelle de la planète, soit individuellement, soit par des partenariats commerciaux dans le monde entier.
7.3.2 Le rôle du responsable orienté services
Dans une entreprise orientée services, les rôles et responsabilités des managers vont évoluer vers une approche de surveillance marquée du système en
place, en fonction des règles définies au sein de l’entreprise. Pour obtenir le
maximum de la part des équipes et des entités, les managers devront « responsabiliser » leurs employés et leur proposer des outils, des droits d’accès
et des règles adaptés pour leur permettre, dans toute situation, de réagir de
façon aussi rapide et adéquate que possible aux demandes de leurs clients.
Une part de cette fonction consiste à planifier, déployer et évaluer les nouveaux processus métiers tout en exploitant le potentiel SOA dans ce sens pour
garantir une certaine flexibilité. Étant donné que l’interaction humaine au
sein d’un bus de services humains, ou simplement dans un processus donné,
a été prévue pour fonctionner suivant les rôles, les compétences et les talents
requis, la fonction des directeurs est d’assurer un encadrement adapté.
Dans de nombreux cas, les compétences des employés sont regroupées et
actualisées au moyen de certifications et de séminaires. Cette approche fournit une vue d’ensemble relativement juste des aptitudes cognitives des collaborateurs. Mais pour obtenir les meilleurs résultats dans une économie orientée services, il y a lieu de définir d’autres aspects non techniques à traiter.
Comme nous l’avons vu dans plusieurs cas pratiques et comme nous le montre l’expérience, il existe des aspects sociologiques et psychologiques qui
déterminent le succès d’un groupe, et en fin de compte d’une entreprise.
D’après les résultats obtenus, les équipes et les entreprises qui fonctionnent
bien, ne disposent pas seulement de structures optimisées et de procédures
efficaces. Elles détiennent également un certain potentiel humain qui fait la
différence. De manière générale, on obtiendra les meilleurs résultats possibles d’une équipe en combinant suivant un certain dosage les talents, les
146
7 Des collaborateurs orientés services
compétences et les tempéraments de chacun. La tâche d’un directeur est donc
de veiller au bon dosage.
Il existe des outils d’aide aux tâches d’encadrement, comme les registres
d’employés qui permettent de consigner non seulement les connaissances
techniques ou les diplômes obtenus, mais aussi de dresser un portrait du
talent et du tempérament des collaborateurs, en donnant une représentation
exacte des tâches, des missions, des activités que le collaborateur apprécie ou
n’apprécie pas. Un registre qui met l’accent sur les talents et les préférences
des collaborateurs est idéal pour permettre au directeur d’assurer un bon
encadrement de ses équipes. Ce registre met en avant des caractéristiques
(par exemple sur les personnes les mieux à même de collaborer entre elles)
afin d’éviter tout conflit interne entre collaborateurs.
Dans de telles conditions, un directeur doit faire preuve de certaines compétences sociologiques et psychologiques. Mais il existe des motivateurs qui
savent trouver les « forces » de chacun pour atteindre un objectif commun et
fournir un service conforme aux attentes du client qui sera ainsi fidélisé.
D’après des résultats de travaux de recherche scientifique, dans toute entreprise, organisation ou groupe, il est possible de trouver un nombre suffisant
de ressources nécessaires pour mener à bien un projet donné. Dans les plus
petites entreprises, il faut tisser davantage de liens coopératifs solides. À cette
fin, il existe des plates-formes, des outils et des services de conseil permettant
d’aboutir, dans toutes les circonstances, à une exploitation orientée objectifs,
autrement dit orientée services.
En tant que lecteur, vous ne serez peut être pas immédiatement convaincu.
Nous vous demandons néanmoins d’étudier votre cas personnel, que vous
soyez directeur ou qu vous exerciez une autre fonction. Pensez à votre contribution dans la réalisation des objectifs de l’entreprise, dans la mise en place
de la stratégie de l’unité pour laquelle vous travaillez. Vous vous rendrez
rapidement compte que pour atteindre les objectifs financiers, il faut faire
face à une multitude d’imprévus, souvent liés au facteur humain. Si vous
réussissez à identifier les moindres étapes dans votre parcours, que vous
parvenez à exploiter vos talents personnels pour remplir les objectifs, votre
motivation personnelle s’en trouvera stimulée et vous déploierez des efforts,
souvent supérieurs à vos niveaux de performance habituels.
147
SOA for Profit
Dans ce chapitre, nous avons évoqué les contrats de niveau de service (SLA)
entre les divers fournisseurs et consommateurs de services. Ces niveaux de
services dépendent de la motivation des employés impliqués. Si vous réussissez dans cette démarche, les SLA pourront être ajustés et vous parviendrez à
accroître le niveau de satisfaction de vos clients et de vos employés. Finie
l’opposition du type « eux, là haut, et nous, ici en bas » ou encore « eux, ils ne
sont pas concernés, c’est nous qui sommes au courant », une attitude courante
de la part des salariés. Par contre, vous obtiendrez un réseau dans lequel
chaque directeur joue le rôle d’un coach plutôt que celui d’un simple chef
donnant des instructions.
7.4 Synthèse
Nous venons de décrire une série de nouveaux rôles essentiels pour l’engagement de l’entreprise dans la démarche SOA. Notons ici un poste clé : celui
du médiateur entre le métier et le service informatique que nous appelons
l’architecte d’entreprise. Dans ce contexte, le rôle d’un responsable de registres de services devient essentiel pour obtenir les meilleurs résultats, et, en
particulier, en ce qui concerne les aspects de gouvernance SOA.
Certains rôles ne sont pas remplis par des collaborateurs, mais tous les aspects
des rôles décrits dans ce chapitre sont importants dans une entreprise souhaitant tirer le meilleur parti de la SOA. Suivant la taille de l’entreprise, il peut
y avoir des équipes de responsables de registre de services ou bien une équipe
architecturale confirmée qui interviennent comme des acteurs clé. Dans
d’autres cas, une seule personne peut assumer plusieurs rôles.
Enfin, il faut tenir compte de l’impact de la SOA sur les salariés dans l’entreprise. Tous les collaborateurs orientés services assisteront à un changement
vers une structure plus souple qui accorde des libertés, mais qui exige une
certaine discipline et un traitement équitable de toutes les parties engagées.
148
8 Comment se préparer à la SOA ?
8.1 Introduction
Les principes de la SOA sont plutôt simples à comprendre. Nous avons mis
en évidence sa valeur ; étudions maintenant la méthode à adopter pour s’y
atteler. À l’heure d’entreprendre notre voyage, le paysage ressemble davantage à un chemin sinueux qui s’enfonce dans la jungle qu’à une route large,
droite et balisée. Si, globalement, la situation semble claire, définir une stratégie, une feuille de route, s’avère plus problématique et semé d’embûches.
Une approche globale à l’échelle de l’entreprise, le plus souvent hiérarchisée
de haut en bas, est pour le moins dangereuse. Cela implique de combler un
fossé organisationnel et technologique considérable, tâche que la plupart des
membres du conseil d’administration hésiteront à exécuter, à juste titre. Les
initiatives informatiques prometteuses et grandioses qui se sont par le passé
soldées par plusieurs échecs, ont entamé leur enthousiasme vis-à-vis d’investissements conséquents.
D’autre part, reléguer la SOA au rang d’un domaine d’application de peu d’envergure et au gain potentiel limité, sans prendre de risque, ne fera que renforcer son statut d’initiative anecdotique, sans grand intérêt pour l’entreprise.
Le déploiement d’une solution SOA intégrée telle quelle, dans l’espoir d’obtenir tous les bénéfices escomptés, peut également être tentant. Ce type de
projet a de fortes chances de fonctionner, étant donné que la technologie a
mûri et qu’un nombre croissant de compétences SOA reste à découvrir. Toutefois, cette solution ne correspond pas entièrement à l’ensemble des domaines visés, étant donné qu’elle est axée uniquement sur des problèmes informatiques pragmatiques.
Comme toujours, la solution doit être adaptée à un contexte donné, à des
besoins et à des objectifs particuliers. Les points forts et les points faibles de
l’entreprise doivent être pris en considération dans une approche progressive.
Le présent chapitre décrit les caractéristiques et certaines des étapes indispensables d’une telle approche. Mais avant toute chose, une vision claire de
149
SOA for Profit
la situation s’impose afin de définir et de hiérarchiser les premiers stades. Le
présent chapitre offre un outil pour évaluer la maturité SOA de votre entreprise afin de vous préparer au mieux à cette approche. Le modèle de maturité
indique si vous êtes prêt uniquement pour certains projets SOA ou pour un
déploiement de la SOA à l’échelle de l’entreprise. Il vous dévoilera également
les secteurs à améliorer lorsque vous déciderez de déployer la SOA à l’échelle
de l’entreprise.
8.2 Modèle de maturité SOA
Pourquoi un modèle de maturité ?
La SOA implique un grand nombre de disciplines et de travaux car elle se
situe au carrefour de l’architecture, de l’informatique et de l’entreprise. De
nouveaux processus sont nécessaires, impliquant l’adaptation de l’entreprise.
La mise en œuvre de la SOA évoluera en permanence, elle aura besoin de
s’adapter, d’être gérée et, disons-le, d’être gouvernée. Il ne s’agit pas d’un
objectif qui peut être atteint une fois pour toutes : le but de la SOA est de
soutenir les objectifs de l’entreprise et de s’adapter aux nouveaux défis auxquels les sociétés sont confrontées. De fait, l’amélioration des capacités SOA
de l’entreprise ne peut être obtenue qu’en tirant simultanément plusieurs
cordes dès le début, mais à des vitesses différentes et, selon le niveau de
maturité de chaque secteur clé scrupuleusement identifié.
Le modèle de maturité présenté ci-après correspond à la caractéristique multidimensionnelle de la SOA.
Description du modèle de maturité SOA
Le modèle s’appuie sur une matrice de maturité composée de secteurs clés :
sujets à aborder et niveaux de maturité pouvant être atteints pour chacun des
niveaux. Cette matrice fonctionne selon des points de contrôle permettant de
mesurer le niveau de maturité.
Secteurs clés SOA
Le modèle identifie 20 secteurs différents requérant une attention particulière afin de parvenir à une SOA exhaustive. Ces secteurs clés sont regroupés
dans les catégories suivantes : Processus, Technologie et Personnel.
•
Le processus traite des secteurs étroitement liés à l’incorporation de
l’architecture et de la gouvernance au sein de l’entreprise, deux des prérequis principaux pour la SOA.
150
8 Comment se préparer à la SOA ?
•
•
La technologie est la deuxième catégorie axée sur la façon dont les systèmes se décomposent et sont rendus souples ainsi que sur les normes/
standards utilisés.
Le personnel traite des compétences, de l’état d’esprit et de la connaissance nécessaire lors de la mise en œuvre de la SOA.
Catégories N°
Secteurs clés
Processus
1
Engagement et motivation
2
Relations avec les projets
3
Rôles et responsabilités
4
Développement de l’architecture
5
Utilisation de l’architecture
6
Outils architecturaux (méthodologie et logiciels)
7
Gestion de la qualité
8
Gestion du portefeuille de services
9
Vision de l’architecture
10
Alignement métier du système d’information
11
Budgétisation et planification
12
Technologie et standards
13
Subdivision et réutilisation
14
Mise en œuvre de processus métiers dans le système
d’information
15
Souplesse du système d’information (infrastructure et
applications)
16
Sécurité de l’information
17
Compétences SOA du personnel informatique
18
Compétences SOA du personnel métiers
19
Connaissance et état d’esprit SOA du personnel informatique
20
Connaissance et état d’esprit SOA du personnel métiers
Technologie
Personnel
Tableau 8.1 : Vingt secteurs clés de la maturité SOA
Niveaux de maturité SOA
Afin de se faire une idée de l’état des secteurs clés, le modèle leur adjoint une
gamme de niveaux, commençant par le niveau le plus bas (niveau A) pour
terminer au plus élevé (niveau D). En moyenne, il existe trois niveaux pour
chaque secteur clé. Chaque niveau supérieur est plus avantageux que le
niveau précédent en termes de délais (plus rapide), de coûts (meilleur mar-
151
SOA for Profit
ché), et/ou de qualité (meilleure). En utilisant des niveaux, nous pouvons
évaluer sans aucun doute possible la situation actuelle de SOA dans l’organisation. Cette méthode augmente également la capacité d’être informé sur
les objectifs pour une amélioration progressive. Chaque niveau consiste en
des exigences pour chaque secteur clé. Les exigences, ou points de contrôle,
d’un niveau donné regroupent également les exigences des niveaux inférieurs : un secteur clé au niveau B répond aux exigences à la fois du niveau
A et du niveau B. On considère le niveau A comme le plus bas et, par conséquent, indéfini pour ce secteur clé particulier si les exigences concernant ce
niveau ne sont pas remplies.
Points de contrôle de niveaux de maturité SOA
Afin de déterminer les niveaux, le modèle de maturité SOA s’appuie sur un
instrument de mesure objectif. Les exigences pour chaque niveau apparaissent sous la forme de points de contrôle et les questions exigent des réponses
affirmatives afin de se qualifier pour ce niveau. Suivant les points de contrôle,
la maturité SOA peut être évaluée, et le niveau approprié établi pour chaque
secteur clé. Comme chaque niveau supérieur d’un secteur clé est considéré
comme une amélioration, cela signifie que l’on accumule les points de
contrôle : afin d’accéder au niveau B, le secteur clé doit répondre de façon
positive aux points de contrôle à la fois du niveau B et du niveau A.
8.3 Vingt secteurs clés de la maturité SOA
Nous venons de décomposer une pratique SOA en 20 secteurs devant être
représentés lors de la mise en place d’une pratique SOA. Nous allons maintenant détailler brièvement ces secteurs.
1. Engagement et motivation
L’engagement et la motivation des parties prenantes de la SOA sont primordiaux pour garantir le succès de la création et la mise en œuvre de la SOA
dans une entreprise. Nombreuses sont les parties prenantes de la SOA : directeurs informatiques et métiers, architectes, développeurs de produits et de
processus, ingénieurs, testeurs et directeurs de projets et de programmes, qui
doivent en premier lieu accepter, puis comprendre et appliquer la SOA, reconnaissant par là même sa valeur stratégique. La SOA passe d’un choix isolé à
une solution parfaitement intégrée dans tous les processus organisationnels.
152
8 Comment se préparer à la SOA ?
2. Relation avec les projets
La mise en œuvre de la SOA se fait par l’intermédiaire de projets. Par conséquent, les projets doivent commencer par se conformer aux architectures,
standards et principes fondés sur la SOA. Les projets peuvent ainsi devenir
une source importante de retours d’informations et d’idées techniques et non
techniques. Par conséquent, un dialogue constructif entre les architectes et
les équipes de projets s’établira dans l’intérêt de chacun : les architectes tireront les leçons de l’expérience pratique des projets et les directeurs de projet
comprendront pourquoi ils doivent se plier aux contraintes. Cette relation
permet l’alignement entre les projets et l’architecture et prend en compte les
contraintes de chaque partie prenante.
3. Rôles et responsabilités
Expliquer les rôles et responsabilités des architectes permet de prévenir et
de résoudre bien des désaccords et des méprises. On sait clairement qui est
responsable de chaque contribution à l’architecture. Au début d’une approche
SOA, le service informatique sera certainement responsable de l’architecture
et du processus. Dans les entreprises plus anciennes, la responsabilité de la
propriété des processus est transversale.
Si les rôles et responsabilités ne sont pas évidents, il est possible que la mise
en œuvre échoue, provoquant un chaos organisationnel.
4. Développement de l’architecture
Le développement d’une architecture basée sur la SOA peut s’opérer de
diverses manières, depuis des projets autonomes et isolés jusqu’à un processus continu de facilitation. Plus le processus de développement de l’architecture est incorporé dans l’entreprise en tant que processus continu,
plus l’architecture basée sur la SOA apportera de la valeur ajoutée à l’entreprise.
5. Utilisation de l’architecture
Le développement de l’architecture basée sur la SOA n’est pas une fin en
soi. L’architecture doit être utilisée dans une entreprise pour atteindre les
objectifs pour lesquels elle a été développée. L’architecture peut s’utiliser
de diverses manières : de façon purement informative, pour guider les projets individuels, ou en tant qu’instrument de gestion pour l’entreprise toute
entière.
153
SOA for Profit
6. Outils architecturaux (méthodologie et logiciels)
Le développement de l’architecture basée sur la SOA exige des méthodologies
comportant des activités, techniques, outils et produits. Une fois que les outils
sont entièrement intégrés dans le processus de développement de l’architecture, qui s’appuie de préférence sur un référentiel d’entreprise, leur efficacité
et leur rendement n’en sont que plus grands. Dans le cas de la SOA, l’intégration complète d’activités, d’informations et de modélisation technique est
recommandée.
7. Gestion de la qualité
La qualité de l’architecture SOA est primordiale pour une mise en œuvre
réussie. La gestion de la qualité garantit que la qualité, ou du moins la valeur
des architectures mises en œuvre, sera mesurée par évaluation rétroactive,
de façon informelle ou en fonction d’indicateurs. Un processus de qualité peut
être mis en place progressivement, puis intégré au niveau du processus de
qualité de l’entreprise
8. Gestion du portefeuille de services
La SOA s’appuie évidemment sur les services. Les services sont identifiés,
conçus, établis, modifiés puis, à un certain moment, retirés. Le champ d’application et la durée de vie des services doivent être gérés à partir d’une
approche concernant le portefeuille de services conformément aux objectifs
et à la stratégie de l’entreprise. La démarche de base consiste à associer la
gestion des applications et des services. Cela étant, le développement d’avantages tirés des services réutilisés d’application croisée induit le besoin de
durées de vie différentes et, à terme, de financement.
9. Vision de l’architecture SI
Les systèmes d’informations doivent être souples pour s’adapter et évoluer avec
les objectifs de l’entreprise. Il ne faut pas entendre par souplesse le fait d’improviser des changements ad hoc au dernier moment, mais plutôt une action
proactive. Afin de répondre de manière proactive aux changements nécessaires,
une vision claire s’impose, non seulement de l’état actuel des systèmes d’information, mais également des évolutions nécessaires à court et à long terme afin
de faire face aux objectifs et défis technologiques et, surtout, commerciaux.
10. Alignement métier du système d’information
L’architecture SOA trouve sa justification dans la réalisation d’objectifs
métiers. Les atteindre n’est qu’un début, mais soutenir les changements
métiers prévus et faciliter la transformation métiers constituent les objectifs
154
8 Comment se préparer à la SOA ?
finaux. D’où le fait qu’en adaptant l’architecture aux exigences métiers, le
degré d’alignement du processus d’architecture sur les capacités et objectifs
métiers devient crucial.
11. Budgétisation et planification
La mise en œuvre de la SOA implique une budgétisation et une planification.
Pour empêcher les initiatives SOA de se disperser et pour les rendre plus
tangibles, il est nécessaire de planifier et de budgétiser les projets SOA. Cela
peut aller du calcul du retour sur investissement de chaque projet à l’optimisation continue de processus de planification et de contrôle.
12. Technologie et standards
La mise en œuvre de la SOA doit s’appuyer sur un socle technologique solide
afin d’offrir les bénéfices attendus. La technologie et les standards doivent
être choisis avec soin. Ce choix peut aller d’une adoption ad hoc en passant
par l’anticipation de nouvelles technologies et de nouveaux standards.
13. Décomposition et réutilisation
L’adaptabilité provient de la réutilisation, laquelle implique la décomposition. Cette réutilisation par décomposition ne constitue pas une évolution
spontanée. Certains résultats peuvent être atteints en capitalisant d’un projet à l’autre. En revanche, la valeur réelle est obtenue en assurant la conception, la planification, la gestion et, plus difficile mais plus efficace, le financement.
14. Mise en œuvre de processus métiers dans le système d’information
La SOA sous-entend que la mise en œuvre des processus métiers fait partie
des systèmes d’information. Cela peut avoir lieu au sein des silos existants
pour commencer, puis s’étendre aux processus contrôlés de bout en bout
parmi plusieurs secteurs d’activité pour une amélioration continue du rendement de l’entreprise.
15. Souplesse du système d’information (infrastructure et applications)
Les entreprises s’organisent traditionnellement au sein de silos gérant leurs
propres applications, matériel informatique et fonctionnalités. Ces structures
de système d’information seront décomposées puis recomposées en éléments
divisibles, réutilisables, souples et modulaires. Les systèmes d’information
deviendront virtuels ; dès lors, il n’est plus pertinent de connaître la plateforme sur laquelle fonctionne un composant.
155
SOA for Profit
16. Sécurité de l’information
La sécurité des systèmes et composants distribués dans un environnement
SOA est une préoccupation communément répandue. La sécurité des services
Internet sera (bientôt) traitée par des standards et des produits. D’autres
problèmes, tels que la stratégie de sécurité de l’entreprise, la responsabilité
juridique entre partenaires commerciaux et une communication sûre sur l’infrastructure partagée, demandent une attention particulière et un consensus.
La sécurité de l’information peut aller d’une attitude réactive à une attitude
largement proactive fondée sur une stratégie de sécurité informatique.
17. Compétences SOA du personnel informatique
Dans un environnement SOA, les professionnels de l’informatique concernés
doivent disposer des compétences requises. La SOA a une influence importante sur les professionnels de l’informatique suivants : architectes informatiques, analystes informatiques, concepteurs, ingénieurs en logiciels, ingénieurs d’infrastructure, testeurs et ingénieurs de maintenance.
18. Compétences SOA du personnel métiers
Dans un environnement SOA, les professionnels métiers concernés doivent
disposer des compétences requises. La SOA a une influence importante sur
les professionnels métiers suivants : architectes d’entreprise, analystes d’entreprises, concepteurs de processus, testeurs et employés de maintenance
fonctionnelle.
19. Connaissance et état d’esprit SOA du personnel informatique
L’orientation services n’est pas seulement un style architectural, c’est également une façon de penser en termes de services et de réutilisation de ces services, et non pas de réinventer la roue. Les informaticiens doivent comprendre
et utiliser ce paradigme afin que l’entreprise puisse récolter les bénéfices de la
SOA. Une des gageures pour les informaticiens est de penser en termes de
réutilisation plutôt qu’en termes de re-conception de ce qui existe déjà.
20. État d’esprit et connaissance SOA du personnel métiers
L’orientation services n’est pas seulement un style architectural, c’est également une façon de penser en termes de services et de réutilisation de ces
services. Le personnel métiers doit comprendre et utiliser ce paradigme afin
que l’entreprise puisse récolter les bénéfices de la SOA. Une des gageures
pour le personnel métiers est de penser en termes de fonctionnalités réutilisables et de dissocier, d’une part, un processus métiers et d’autres part les
fonctionnalités (services) qui seront utilisés dans le cadre de ce processus.
156
8 Comment se préparer à la SOA ?
8.4 Tout ne se fera pas nécessairement en un jour
Chacun des 20 facteurs d’une pratique effective de la SOA doit susciter une
attention suffisante. Cela ne signifie pas pour autant que chacun de ces facteurs requière en permanence la même attention.
Premièrement, tous les facteurs ne sont pas également pertinents au début.
La gestion de la qualité deviendra sans aucun doute une préoccupation clé à
un moment donné, mais les entreprises toujours en phase d’élaboration d’une
pratique SOA peuvent se concentrer de façon plus productive sur l’engagement et la motivation, la vision de l’architecture, la technologie et les standards, la sécurité de l’information et la connaissance et l’état d’esprit SOA. La
gestion de la qualité viendra en temps voulu.
Deuxièmement, tout domaine donné ne doit atteindre d’emblée son développement complet. Différents niveaux de maturité peuvent être distingués dans
chacun des secteurs différents. L’engagement et la motivation passent par
plusieurs stades de croissance. Une approche SOA débute souvent par le
financement de quelques initiatives SOA. À un niveau plus avancé de maturité, l’approche SOA est soutenue par le management de l’entreprise : la SOA
devient importante pour l’entreprise. À l’étape finale, la SOA est considérée
comme un processus intégré avec d’autres processus d’entreprise.
Cette croissance différenciée fait que chaque domaine clé suit sa propre voie
de développement avec de multiples niveaux. La nature et le nombre de
niveaux de chaque voie de développement dépendent entièrement du caractère des préoccupations individuelles et sont établis indépendamment les unes
des autres. Comme le montre le Tableau 8.4, en pratique, la voie de développement dans la plupart des secteurs passe par trois voire quatre niveaux.
La distinction entre les secteurs clés, suivant chacun sa propre voie de développement, permet la mise en œuvre et l’optimisation des pratiques SOA étape par
étape. Cette approche fournit une directive sur le niveau d’attention à apporter,
à un moment précis, à chaque domaine de préoccupation. Ainsi, l’entreprise peut
prendre des mesures gérables d’amélioration dans ces secteurs précises offrant
une grande valeur ajoutée par rapport au statut de l’entreprise. À cette fin, nous
devons déterminer le cours optimal que l’entreprise doit prendre pour naviguer
entre toutes les cellules du tableau ci-après. Quel niveau devons-nous nous efforcer d’atteindre dans un domaine particulier à un moment donné ? La réponse à
cette question se trouve synthétisée dans le modèle de maturité SOA.
157
SOA for Profit
Secteur clé
Niveau A
Niveau B
Niveau C
L’approche
SOA est
soutenue par
le
management
de l’entreprise
L’approche
SOA est
intégrée dans
le processus de
l’entreprise
Architecture
Le processus
pour diffuser la architectural
communication prend en
compte les
retours
d’informations
des projets
Les architectes,
commerciaux
et
informaticiens
établissent
ensemble
l’architecture
du projet
1
Engagement et Budget et
motivation
temps
disponibles
pour les
initiatives SOA
2
Relation avec
les projets
3
Rôles et
Service
responsabilités informatique
chargé de
l’architecture
et du
processus
Les services
informatique et
métiers
collaborent au
processus
architectural
La
responsabilité
de la propriété
du processus
est
transversale
4
Développement Architecture
de l’architecture sous forme de
projets
Architecture en
tant que
processus
transversal
Architecture en
tant que
processus de
facilitation
5
Utilisation de
l’architecture
Architecture
utilisée de
façon
informative
Architecture
utilisée pour
diriger/
conduire le
contenu
Architecture
intégrée à
l’entreprise
6
Outils
architecturaux
(méthodologie
et logiciels)
Initiatives non
coordonnées
Allégement de
l’outillage et
stratégie
d’intégration,
processus
d’architecture
global défini
L’outillage est
exhaustif et
intégré, le
processus
d’architecture
global
formalisé
8
Gestion du
portefeuille de
services
Les durées de
Contrats de
vie des services niveau de
dépendent de services
celles des
applications
qui les livrent
158
Niveau D
Dialogue
continu entre
les architectes,
commerciaux
et
informaticiens
Durée de vie
Financement
prévue (y
de l’utilisation
compris retrait) des services
(marché des
services)
8 Comment se préparer à la SOA ?
Secteur clé
Niveau A
Niveau B
Niveau C
Niveau D
9
Vision de
l’architecture
Vision d’une
architecture
« en l’état »
Vision
d’évolutions à
court terme
Vision
d’architecture
à long terme
Alignement
continue de la
vision sur les
objectifs
métier, à court
et à long terme
10
Alignement
métier des
systèmes
d’information
Les applications
et services sont
conçus pour
répondre aux
objectifs métier
(motivés
commercialement)
Les
applications et
services sont
testés en
termes de
compatibilité
avec les
objectifs métier
Le processus
architectural
soutient
l’activité
métiers
Le processus
architectural
facilite la
transformation
métiers
11
Budgétisation
et planification
Besoin de justifier Projet SOA
formellement un spécifique
retour sur
investissement
direct pour
chaque projet
métier SOA
impacté
Générique
entreprise
Optimisation
continue du
processus de
budgétisation
et de
planification
12
Technologie et
standards
Technologie ad Référentiel
hoc choisie en basé sur une
cas de besoin
informatique
définie et
prouvée
Stratégie
motivée
Anticipation des
changements
technologiques
et adoption des
nouveaux
standards
13
Décomposition Réutilisation
et réutilisation non
coordonnée
La réutilisation
est coordonnée
en
informatique
(services
techniques)
La réutilisation
est coordonnée
au niveau
métiers
(services
métiers)
Les services
métiers et informatique sont
subdivisés et la
réutilisation est
répandue.
14
Mise en œuvre
des processus
métiers dans le
système
d’information
Processus
transversal
Surveillance de
l’activité
métiers
(Business
Activity
Monitoring BAM)
Les services
métiers et
informatique
collaborent
pour établir et
déployer des
processus
métiers
Services
métiers
existants au
sein de silos
159
SOA for Profit
Secteur clé
Niveau A
Niveau B
Niveau C
Niveau D
15
Souplesse du
système
d’information
(infrastructure
et application)
Le système
d’information
basé sur les
silos
comprenant
une application
basée sur les
services et du
matériel
informatique
pour les gérer
Certaines
applications et
infrastructures
sont partagées
entre des silos
(flous) à cause
de la
rationalisation.
Système
d’information
orienté
processus,
reconfigurable
et urbanisé.
Virtualisation
des systèmes
d’information –
entreprise
désassociés
16
Sécurité de
l’information
Réactive
Individuelle
Collective
Proactive
17
Compétences
SOA du
personnel
informatique
Basiques
Modérées
Développées
18
Compétences
SOA du personnel métiers
Basiques
Modérées
Développées
19
Connaissance
et état d’esprit
SOA du
personnel
informatique
Sensibilisation
partielle
Sensibilisation
au niveau de
l’entreprise
État d’esprit
SOA normal
20 Connaissance
et état d’esprit
SOA du
personnel
métiers
Sensibilisation
partielle
Sensibilisation
au niveau de
l’entreprise
État d’esprit
SOA normal
Tableau 8.2 : Niveaux de maturité dans chaque secteur clé
Le cas de figure du chaos Pas d’inquiétude à avoir, la mise en œuvre de la SOA ne se fera pas ex nihilo. Si vous
avez cette impression, essayez simplement d’imaginer à quoi ressembleraient les
pratiques dans une entreprise se trouvant à zéro dans chaque secteur clé du modèle
de maturité. L’exemple fictif ci-après s’appuie sur un mélange de plusieurs cas
réels.
160
8 Comment se préparer à la SOA ?
Engagement et motivation
Les managers ont entendu parler de la SOA, et, selon eux, il s’agit de la dernière
technique à la mode. Le département informatique s’y attellera en utilisant son ­propre
budget, vu qu’un directeur informatique est responsable de l’initiative SOA. Ce qui
pose problème, c’est que cette personne est bien trop occupée à maintenir le système
actuel.
Budgétisation et planification
La maintenance coûte 75 % des sommes attribuées à l’informatique. L’informaticien
en question se dit que, si un projet nouveau, de grande envergure et prioritaire
­disposant d’un financement spécial se présentait, il pourrait commencer une étude
SOA en parallèle qu’il financerait en facturant à peine 10 % de plus pour ce projet
­prioritaire.
Alignement métier du système d’information
Pour l’instant, faisons profil bas. Les relations entre les services métiers et informatique sont déjà suffisamment tendues. Enfin officiellement, tout va bien : le nombre de
demandes émanant des métiers qui sont refusées par le service informatique est très
bas mais, en réalité les services métier évitent de demander au service informatique
d’entreprendre quoi que ce soit, étant donné que la mise en œuvre d’une solution est
toujours trop longue (6 mois minimum) et bien trop onéreuse (avec un nombre à
6 chiffres à la clé).
Mise en œuvre de processus métiers dans le système d’information
En quittant le directeur informatique, vous vous souvenez avoir entendu parler
de plusieurs raisons à l’origine de ces problèmes. Les applications métiers
­fondamentales sont exécutées sur un ordinateur central, il existe de nombreuses
applications plus récentes sur des systèmes UNIX et certains portails. Chaque
application remplit une fonction spécifique et gère ses propres données. Jusqu’à
présent, en cas de besoin, des liens étaient établis entre elles. Mais désormais
la situation a des allures de pelote de laine que personne n’est capable de démêler.
Souplesse du système d’information (infrastructure et applications)
L’année dernière, un entrepôt de données de consultation a été mis en œuvre. Chaque
soir, de nouvelles données provenant de chaque application étaient stockées dans
cet entrepôt de données. Les nouvelles applications utilisent l’entrepôt en tant que
référentiel de données. Pour l’instant, cela permet de connecter de nouvelles applications sans devoir gérer les connexions.
161
SOA for Profit
Sécurité de l’information
L’entrepôt ne fonctionne pas en temps réel. De fait, certaines applications utilisent
des données ayant déjà été modifiées par une autre application. Il existe plusieurs
exemples d’incohérence entre les applications. Le service informatique s’efforce de
détecter et de corriger ces erreurs.
Relations entre les projets
Un autre angle d’approche, selon vous, pourrait consister à trouver un projet de mise
en route qui s’adapterait à une SOA de base, conçue par des architectes de l’entreprise. Malheureusement, comme certains directeurs des opérations informatiques
vous le diront, les projets refusent le plus souvent d’utiliser des standards architecturaux et conçoivent des architectures ad hoc uniques. Ils affirment que les instructions
« tombées d’une tour d’ivoire » ne peuvent être mises en œuvre et qu’elles ne marchent pas.
Rôles et responsabilités
Le rétablissement du référentiel d’architecture et la redéfinition de l’architecture cible
pourraient contribuer au lancement d’un cercle vertueux. Après avoir envoyé des
e‑mails, passé des coups de téléphone et bu du café avec vos collègues, vous parvenez
à la conclusion que les architectes portent plusieurs casquettes et que l’architecture
peut être modifiée par toute personne disponible le moment venu.
Développement de l’architecture
Par conséquent, l’architecture est développée au sein de projets, si quelqu’un pense
à le faire.
Utilisation de l’architecture
Quoi qu’il en soit, l’architecture proposée reste souvent inutilisée pour les raisons
susmentionnées.
Vision de l’architecture
Par conséquent, la description architecturale est éparpillée dans la documentation du
projet, si elle n’est pas simplement stockée dans le cerveau des équipes du projet.
Outils architecturaux (méthodologie et logiciels)
Si vous pouviez rassembler toute la documentation produite, vous trouveriez un
ensemble hétérogène d’UML : diagrammes méridiens consistant en divers logiciels
(avec ou sans licence appropriée), description textuelle, présentations PowerPoint,
etc., qui sont le plus souvent obsolètes.
162
8 Comment se préparer à la SOA ?
Gestion de la qualité
Les résultats de l’architecture peuvent, bien évidemment, ne jamais être évalués étant
donné que les architectes de projet s’occupent de plusieurs projets en même temps.
Compétences SOA
En réalité, les architectes de projet sont souvent des concepteurs de logiciels jeunes
et motivés faisant de leur mieux pour établir une architecture convenable, à l’instar
de celui qui vous a parlé du présent ouvrage. La dernière fois que vous l’avez vu, il
vous a dit qu’il quittait la société.
Subdivision et réutilisation
Il a travaillé dans le centre de compétence des services Internet de votre entreprise.
Il a participé au développement d’un outillage XML incorporant la description de tous
les objets métier et du vocabulaire commun de l’entreprise. En raison d’une pénurie
de ressources, il a essayé de capitaliser d’un projet à l’autre ; mais le coût de l’adaptation de ce qui avait déjà été fait s’est avéré prohibitif, et le plus souvent, les projets
repartaient de la case départ.
Gestion du portefeuille de services
Son équipe était chargée du développement des services Internet par le biais de
projets mais, étant donné que personne ne l’a organisé, une pandémie de services
Internet s’est répandue dans toutes les applications. À un moment donné, les services
ont dû être fermés les uns après les autres : si un utilisateur se plaignait, cela signifiait
que le service était toujours utilisable. Sinon, il ne fonctionnait plus.
Connaissance et état d’esprit SOA
En désespoir de cause, vous rangez le présent ouvrage dans un tiroir et décidez pour
de bon de tout oublier au sujet de la SOA. Mais, vous n’oublierez jamais cette leçon :
une mise en œuvre réussie de la SOA demande des pratiques métiers et informatiques
mûres à tous les niveaux de l’entreprise.
8.5 Utilisation du modèle de maturité SOA
Une fois le niveau de maturité de chaque secteur clé mesuré, les résultats
doivent être utilisés pour déterminer quelles actions sont nécessaires à l’amélioration. Ces actions doivent être hiérarchisées. Naturellement, tous les secteurs clés ne sont pas d’égale importance et atteindre un certain niveau de
maturité dans un domaine clé peut dépendre de la réalisation d’un autre. Il
163
SOA for Profit
est inutile de gérer la qualité offerte par l’architecture si la vision de cette
architecture n’est pas claire. De nombreuses interdépendances peuvent apparaître entre les différents niveaux des secteurs clés.
Par conséquent, tous les niveaux et secteurs clés sont liés les uns aux autres
dans un modèle de maturité SOA. Ceci a pour but de déterminer les priorités
et interdépendances internes entre les niveaux et les secteurs clés. L’axe vertical de la matrice indique les secteurs clés et l’axe horizontal illustre le degré
de maturité. Sur la matrice, chaque niveau est relié à une note spécifique des
13 degrés de maturité. Lorsqu’une case reste vide, cela indique qu’atteindre
une maturité supérieure dans un secteur clé ne dépend pas de la maturité
d’un autre secteur clé. Au final, il n’y a pas de gradation entre les niveaux :
tant qu’un secteur clé n’a pas entièrement classifié en tant que niveau B, il
reste au niveau A.
Stade
Secteur clé
0 1 2 3 4 5 6 7 8 9 10 11 12 13
1
Engagement et motivation
2
Relations avec les projets
3
Rôles et responsabilités
A
4
Développement de
l’architecture
A
5
Utilisation de l’architecture
6
Outils architecturaux
(méthodologie et logiciels)
7
Gestion de la qualité
8
Gestion du portefeuille de
services
9
Vision de l’architecture
10
Alignement métier du
système d’information
11
Budgétisation et
planification
12
Technologie et standards
13
Subdivision et réutilisation
14
Mise en œuvre de
processus métiers dans le
système d’information
164
A
B
A
C
B
C
B
C
B
A
C
B
A
C
B
A
B
A
B
A
D
D
C
B
D
C
D
C
B
A
D
C
B
A
C
C
B
A
C
B
A
A
D
B
D
C
D
C
D
8 Comment se préparer à la SOA ?
15
Souplesse du système
d’information
(infrastructure et
applications)
A
16
Sécurité de l’information
17
Compétences SOA du
personnel informatique
A
B
C
18
Compétences SOA du
personnel métiers
A
B
C
19
Connaissance et état
d’esprit SOA du personnel
informatique
A
B
C
20 Connaissance et état
d’esprit SOA du personnel
métiers
A
B
C
A
B
C
B
C
D
D
Tableau 8.3 : Modèle de maturité SOA
L’objet du présent modèle est d’offrir aux parties prenantes une vision claire
de leur maturité SOA. Les points forts et les points faibles apparaîtront graphiquement sur un tableau simple d’utilisation. Le modèle aide le processus
de définition des points d’amélioration et la discussion d’une stratégie et d’un
plan d’action pour passer à un niveau de rendement supérieur.
Le modèle permet l’identification de ce qui marche déjà ou ce qui a besoin
d’une légère mise au point, ce qui est fiable, ce qui doit être amélioré, mis en
œuvre ou fait différemment.
Le modèle se lit de gauche à droite, de sorte que les secteurs clés dont les
niveaux ont une note faible sont à améliorer en premier. En conséquence des
interdépendances entre les niveaux et secteurs clés, les secteurs à droite du
modèle offriront moins de rendement du capital investi s’ils sont mis en
œuvre avant les autres.
Ainsi, il est possible de passer d’une étape à l’autre progressivement jusqu’au
stade 13. Néanmoins, ce dernier stade représente un niveau de perfection
auquel toutes les entreprises n’aspirent pas forcément. Le principe du just
enough, just in time s’applique également à la pratique SOA. Il est plus judicieux de se fixer un stade inférieur comme objectif initial : le stade 3, par
exemple. Une fois ce but atteint, l’entreprise est davantage disposée à déployer
une approche SOA et peut alors décider que ce niveau est suffisant ou se fixer
165
SOA for Profit
comme nouvel objectif un stade supérieur (stade 6, par exemple). Dans ce
processus, il est possible de distinguer différents stades comme le montre le
Tableau 8.4.
Stade
Prêt pour SOA
Caractéristiques
0
Exécuter un projet pilote SOA
Aucune sensibilisation, compétence,
engagement, standard, principe, meilleure
pratique
3
Exécuter des projets en
relation avec la SOA au sein
des sections isolées de
l’entreprise
Les bases sont en place, mais il reste
beaucoup à apprendre et à améliorer. Il est
important de disposer d’un processus dans
lequel les expériences d’apprentissage
peuvent être incorporées et dans lequel les
standards, principes et meilleures pratiques
seront développés et améliorés.
6
Exécuter des projets en
relation avec la SOA à
l’échelle de l’entreprise
Le nombre de standards, principes et
meilleures pratiques est croissant.
L’expérience est consolidée et réutilisée
dans l’entreprise.
9
Exécuter tous les projets en
relation avec la SOA à
l’échelle de l’entreprise ainsi
que le projet de
transformation métier liée à la
SOA
Une expérience substantielle permet le
déploiement de la SOA. Les standards,
principes et meilleures pratiques sont
largement disponibles et déployés à
l’échelle de l’entreprise.
13
Transformation métier
continue
Le déploiement de la SOA est
complètement incorporé dans les processus
de l’entreprise. Les produits et processus
sont optimisés en permanence, sous des
influences externes et internes.
Tableau 8.4 : Stades de disponibilité SOA
Notre expérience montre que la majorité des entreprises essaient d’atteindre
le stade 3 ou viennent de l’atteindre. À ce niveau, la SOA revêt un caractère
raisonnable. Elle produit des résultats, mais la situation pourrait être meilleure.
Les entreprises ayant atteint le stade 6 constateront un succès accru grâce à
l’usage d’une approche SOA. À partir de ce stade, il peut être intéressant de
considérer si oui ou non il importe de continuer jusqu’au stade 9. Toutes les
entreprises ne feront pas ce choix. Au stade 9, l’entreprise ne produira de
profits supplémentaires que si elle est disposée à le faire dans d’autres secteurs de structure et de gestion.
166
8 Comment se préparer à la SOA ?
Toutefois, il faut passer par une étape préalable consistant à fixer des objectifs et des priorités : déterminer la position actuelle de l’entreprise selon les
20 secteurs clé. Le statut en l’état peut être représenté dans le modèle de
maturité SOA comme l’illustre le Tableau 8.5.
Stade
Secteur clé
1 Engagement et motivation
0 1 2 3 4 5 6 7 8 9 10 11 12 13
A
B
2 Relations avec les projets
A
3 Rôles et responsabilités
A
4 Développement de
l’architecture
A
5 Utilisation de l’architecture
B
A
B
C
B
A
A
B
B
C
14 Mise en œuvre de processus
métiers dans le système
d’information
C
A
D
C
B
A
A
D
D
B
A
15 Souplesse du système
d’information (infrastructure et
applications)
C
B
A
D
D
B
A
13 Subdivision et réutilisation
C
C
A
11 Budgétisation et planification
C
B
A
10 Alignement métiers du système
d’information
16 Sécurité de l’information
C
A
8 Gestion du portefeuille de services
D
C
B
7 Gestion de la qualité
12 Technologie et standards
C
B
6 Outils architecturaux
(méthodologie et logiciels)
9 Vision de l’architecture
C
B
B
D
C
D
C
D
C
B
C
D
D
17 Compétences SOA du personnel
informatique
A
B
C
18 Compétences SOA du personnel
métiers
A
B
C
19 Connaissance et état d’esprit
SOA du personnel informatique
A
B
C
20 Connaissance et état d’esprit
SOA du personnel métiers
A
B
C
Tableau 8.5 : Modèle de maturité SOA pour un exemple d’entreprise au stade 0
167
SOA for Profit
L’entreprise dans le Tableau 8.5 reste au stade 0 étant donné que le domaine
impliquant la connaissance et l’état d’esprit SOA du personnel métiers n’a
pas été développé du tout. La matrice montre que l’entreprise devrait se
concentrer sur ce domaine. Une fois le niveau de base A atteint, l’entreprise
aura atteint le stade 1. La compétences SOA du personnel métiers devient le
domaine auquel il convient ensuite de s’attacher, afin de passer au stade 3.
Ainsi, nous pouvons concrètement définir une voie de développement.
Le modèle de maturité SOA peut être utilisé à des fins multiples :
•
Que sera la série de développements avec la SOA ?
Parcourez le modèle et examinez la série d’aspects de développement.
Prêtez attention à la façon dont les différents aspects sont en rapport les
uns avec les autres.
•
Avoir une idée plus précise des points forts et des points faibles du fonctionnement actuel.
Remplissez le modèle décrivant la situation actuelle. Les aspects comptabilisant plus de points que la moyenne sont vos points forts. Les aspects en
comptabilisant le moins demandent une plus grande attention de votre part.
•
Anticiper.
Déterminez les objectifs que vous voulez atteindre grâce à la SOA et mettez-les en exergue. Trouvez le niveau de maturité correspondant dans le
modèle et remplissez-le, en décrivant la situation actuelle. Établissez votre
feuille de route en organisant une série d’aspects que vous devez améliorer
pour atteindre le niveau escompté.
8.6 Action ciblée
L’utilisation de la SOA implique plusieurs facteurs. Nous en avons défini vingt,
dont chacun suit sa propre voie de développement. Ils sont bien trop nombreux à surveiller en même temps. Nous utilisons donc le modèle de maturité
SOA pour les hiérarchiser. En représentant l’entreprise sur cette matrice,
nous pouvons déterminer les secteurs clés qui doivent être mis en valeur dans
un futur proche et quel type d’action doit être mené. Ainsi, nous pouvons
prévoir des améliorations ciblées.
Pour ceux qui désirent utiliser le modèle de maturité SOA, l’Annexe offre de
plus amples informations. Pour établir la situation d’une entreprise, chaque
domaine de préoccupation comporte un nombre de points de contrôle à chaque niveau. En utilisant ces points de contrôle, il est possible de déterminer
168
8 Comment se préparer à la SOA ?
si oui ou non l’entreprise a atteint le niveau approprié. Si l’entreprise ne
comptabilise pas tous les points de contrôle d’un niveau particulier, mais veut
toutefois utiliser le modèle de maturité SOA pour atteindre ce niveau, des
actions adaptées peuvent être envisagées. Ces actions découlent en partie des
points de contrôle. En même temps, les actions doivent toujours s’adapter aux
circonstances de l’entreprise. La formulation des améliorations ne doit jamais
être un processus purement mécanique.
8.7 Synthèse
Mettre en place une initiative innovante n’est jamais chose aisée, en particulier
si, comme c’est le cas pour la SOA, de multiples domaines de l’entreprise s’en
trouvent fortement concernés. La SOA déclenche des conséquences en chaîne.
C’est la raison pour laquelle, au lieu d’une méthodologie étape par étape, nous
avons décrit le modèle de maturité SOA qui vous indiquera le chemin à suivre
au bon rythme vers une cible SOA spécifique correspondant le mieux à votre
entreprise. Le modèle de maturité SOA peut être considéré comme une boussole et une machette pour vous frayer un chemin dans la jungle SOA. Il vous
dit exactement les secteurs à améliorer, selon vos ambitions.
Le modèle de maturité SOA comporte vingt facteurs ayant une influence sur
la mise en œuvre réussie de la SOA. Il s’agit d’un nombre déjà réduit, étant
donné que de nombreux autres facteurs ont été évincés pour rendre le modèle
utilisable. Aucune entreprise n’a assez de temps, d’argent et de ressources
pour affronter tous ces sujets, en particulier dans la mesure où la SOA n’est
certainement pas une fin en soi, mais plutôt un moyen de faciliter l’activité
métiers. C’est la raison pour laquelle il est nécessaire de déterminer une
stratégie qui aborde précisément chaque problème, au moment opportun, ni
trop tôt ni, surtout, trop tard.
Selon le secteur industriel de l’entreprise, son historique et sa stratégie, certains secteurs clés auront déjà été abordés de différentes manières. En outre,
des différences dans les objectifs métiers feront varier considérablement les
actions initiales de l’entreprise.
L’analyse du modèle de maturité SOA peut vous aider à canaliser vos efforts
et vos investissements vers des secteurs qui en ont le plus besoin. De fait, une
stratégie transversale à moyen terme voit le jour, sous la forme de divers
projets pour préparer votre entreprise à la SOA.
169
SOA for Profit
Outre ces considérations, dont le but est d’éviter de perdre du temps et de
l’argent dans des activités inefficaces, une initiative SOA naissante doit également asseoir une crédibilité en offrant, dans les meilleurs délais, des résultats visibles et de la valeur pour l’entreprise. Il s’agit d’une des raisons les
plus importantes pour toujours appliquer une initiative SOA à des projets
concrets. Au chapitre suivant, nous aborderons la manière de trouver des
projets métiers adaptés.
170
9 Comment démarrer la SOA ?
9.1 Introduction
Vous avez décidé de mettre en œuvre la SOA. Nous avons déjà décrit les
conséquences et l’impact de cette démarche. Nous allons maintenant expliquer comment établir la feuille de route pour la mise en œuvre de la SOA. Par
quoi commencer ? Quelles mesures prendre et à quel moment ? Quelles
conditions préalables respecter ? Dans quelle mesure un projet SOA diffèret-il d’un autre projet ?
Dans le présent chapitre, nous allons tout d’abord présenter une méthode globale pour définir les mesures à prendre. Ensuite, nous examinerons plus en
détail les « points d’entrée » qui caractérisent les projets SOA. Penser en termes
de points d’entrée vous aidera à localiser les projets SOA potentiels de votre
entreprise et à en déterminer plus clairement la valeur métiers.
9.2 Votre feuille de route SOA
La mise en œuvre de la SOA déclenche des conséquences en chaîne. Autrement dit, la stratégie SOA ne peut pratiquement jamais être mise en œuvre
dans le cadre d’un programme ou d’un projet unique ; elle nécessite en effet
une mise en œuvre progressive. Cette dernière n’est pas guidée par un objectif de finalisation du projet, mais plutôt par le souhait de concrétiser les objectifs de l’entreprise tout en exploitant la SOA en tant que style architectural.
La mise en œuvre de la SOA n’est jamais une fin en soi. Premier constat :
aucune feuille de route SOA n’est requise ; vous avez besoin d’une feuille de
route qui conduise à l’objectif réel via la SOA, quel qu’il soit. À cette fin, vous
devez évaluer l’impact de la SOA pour votre entreprise et les objectifs à
atteindre. Dans les précédents chapitres, nous vous avons conseillé d’instaurer un dialogue stratégique entre le service métier et le service informatique,
puis de formuler une vision commerciale SOA finale. Ce n’est qu’à ce stade
que vous déterminerez ce que la SOA peut signifier pour vous et quelles sont
les opportunités de son application. Après tout, la SOA, n’est pas une révolu-
171
SOA for Profit
tion mais une évolution, ce n’est pas le Big Bang. Dès que vous aurez défini
une stratégie pour déterminer de quelle manière l’entreprise pourra tirer
parti de l’architecture SOA, les projets concrets ultérieurs amorcés par l’entreprise concrétiseront cette vision étape après étape. « Penser grand, agir
petit » est une approche qui sied parfaitement.
La Figure 9.1 présente une vue d’ensemble de la SOA au fil du temps. L’établissement de la feuille de route en est un composant.
Stratégie
d’entreprise,
Objectifs
à long terme
Vision
métiers
SOA
Situation
actuelle
Objectifs
métiers
Goulets
d'étranglement,
Opportunités
Points
d’entrée
Maturité
SOA
Feuille
de route
SOA
Points
d’entrée
Projet
Projet métier
Projet métier
Quelles mesures devez-vous
prendre et à quel moment ?
Où en êtes-vous maintenant ?
Que souhaitez-vous réaliser ?
Projet métier
Projet métier
Projet métier
Projet métier
SI générique / SOA
Projet capacitaire
Technologie
Projet capacitaire
Processus
Projet capacitaire
Personnel
Projet capacitaire
Planning de mise en œuvre de la SOA
Stratégie
Analyse
Plan
Introduction
Développement
Action
Figure 9.1 : Approche de mise en œuvre de la SOA
Les données d’entrée de la feuille de route sont les suivantes :
•
Vision commerciale SOA. C’est la note stratégique où apparaît la valeur
ajoutée de la SOA pour votre entreprise.
•
Détermination de la position dans le modèle de maturité SOA. Ce modèle
met en évidence vos atouts et vos points faibles à plusieurs niveaux : Processus, Technologie et Personnel.
172
9 Comment démarrer la SOA ?
•
•
Objectifs commerciaux concrets, goulets d’étranglement et opportunités
liés au déploiement de la SOA.
Points d’entrée correspondant aux caractéristiques des projets SOA.
Le résultat sera la feuille de route SOA avec les principaux composants ci-après :
Les choix de base pour l’organisation et le pilotage.
•
Le choix des projets métiers.
•
Le choix des projets de disponibilité.
•
Les choix de base
Avant d’établir une feuille de route SOA, vous devez choisir un certain nombre de paramètres essentiels pour le processus de mise en œuvre. Le tableau
ci-après répertorie ces choix avec un certain nombre de possibilités, leurs
avantages et inconvénients. Ici, vous devez vous appuyer sur les choix mentionnés sous forme de principes pour guider la mise en œuvre. Ces principes
doivent être intégrés dans votre architecture d’entreprise.
Choix de
base
Possibilités
Avantages
Inconvénients
Qui établit le
contrat de
service
(cahiers des
charges et
conditions
d’un service) ?
Projet
- Le projet obtient le service qu’il
veut
- Vitesse
- Peu d’intérêt dans la
réutilisation
- Risque d’application de
standards non
homogènes
Organe
central
- Peut aller au-delà des projets et
dispose d’une meilleure vision
des opportunités de réutilisation
- Risque de retard
- Risque d’effet « tour
d’ivoire »
Qui pilote le
Entreprise
portefeuille de
service (et
donc la durée
de vie des
services) ?
Service
informatique
- Si l’entreprise est propriétaire
- Les services sont des
des services, il est logique que le composants automatisés
portefeuille soit également
de la fonctionnalité de
piloté à ce niveau.
l’entreprise dont le
service informatique est
souvent le seul à savoir
qui utilise quoi et qui
peut avoir une vue
globale des domaines.
- Si le service informatique est
propriétaire des services, il est
logique que le portefeuille soit
géré à ce niveau.
- Il est étrange que le
service informatique en
tant que concepteur soit
aussi décideur pour des
questions métiers
173
SOA for Profit
Qui gère le
portefeuille de
services en
termes de
délai de
conception ?
Propriétaires
du domaine
- Le propriétaire du domaine se
sent responsable du portefeuille
Organe
central
- Un endroit centralisé où tous les
contrats de services sont gérés.
Qui gère le
Propriétaires
portefeuille de du domaine
services en
termes
d’exécution ?
Qui est le
propriétaire
d’un service à
fournir ?
Le choix des
domaines
174
- Le propriétaire du domaine se
sent responsable de la
fourniture du service
- Nécessite une bonne
distinction entre les
domaines d’activité
- Risque de recouvrement
- Les propriétaires de
domaine doivent
réglementer la gestion de
la surveillance pour euxmêmes
Organe
central
- Un lieu centralisé où la
fourniture de tous les services
est surveillée
Entreprise
- L’entreprise demande et définit - Nécessite une division
les fonctionnalités en termes de
nette de l’entreprise en
services que d’autres
domaines et l’affectation
composants doivent fournir. Il
des services
est alors logique que l’entreprise
soit propriétaire des services.
- La propriété des services va de
pair avec la propriété des
applications dans l’entreprise.
Service
informatique
- Le service informatique
recherche des opportunités de
réutilisation et combine les
fonctionnalités identiques dans
les services fournis à
l’entreprise. Il est alors logique
que le service informatique soit
propriétaire des modules de
construction fonctionnels.
- Le service informatique
ne peut décider lui-même
de la réutilisation des
fonctionnalités dans
l’entreprise.
Entités
- Conformité aux structures
existantes
- Les silos actuels risquent
de se perpétuer
- Les services risquent de
se recouper
Secteurs
fonctionnels :
par exemple
les fonctions
métiers
- Division pure de secteurs
fonctionnels aussi autonomes
que possible
- Structure fonctionnelle
qui ne correspond pas à
la structure
organisationnelle
existante
9 Comment démarrer la SOA ?
Comment les
services sontils financés ?
Comment
l’utilisation
des services
est-elle
calculée et
mise en
place ?
- En général, les projets sont
intégrés dans les structures de
financement en place
- Les projets sont plus
onéreux qu’en temps
normal car ils doivent
prendre en compte
l’aspect de réutilisabilité.
Par le budget - Suscite une motivation pour
central
arriver à des services
réutilisables
- Plus de chance de succès pour
les initiatives SOA
- Réglementation requise
- Financement inapproprié
du budget central
Suivant
usage
- Juste répartition de la charge
- Réglementation requise
Pas du tout
- Pas d’administration pour le recalcul des coûts
Par les
projets
Tableau 9.1 : Choix de base de la mise en œuvre de la SOA
Le choix des projets métiers
La mise en œuvre de la SOA s’effectue principalement dans le cadre de projets métiers où la majorité des services sont identifiés, créés et mis en œuvre.
Sur la Figure 9.1, les premiers projets métiers sont basés sur les « points
d’entrée », c’est-à-dire des projets caractéristiques mis en œuvre pour fournir
les composants de l’infrastructure SOA – et donner une certaine valeur ajoutée à l’entreprise en proposant la fonctionnalité sous la forme de services
éventuellement réutilisables.
Exemples de projets métiers qui se prêtent à l’application SOA :
• Augmentation de la productivité du personnel d’un centre d’appel.
• Accélération des délais de traitement dans le processus de gestion des commandes.
• Mise en œuvre d’un nouveau mode de gestion des relations clients.
• Amélioration des informations destinées aux directeurs seniors.
Trouver le projet pilote parfait peut être un juste milieu entre risque et récompense. Le risque global lié au projet doit être suffisamment faible pour que
vous puissiez prendre les premières mesures SOA en toute sérénité et les
résultats escomptés se révéler suffisamment conséquents pour donner un
sens à l’initiative.
175
SOA for Profit
Il faut maintenir les risques à un niveau assez bas pour optimiser les probabilités d’achèvement dans les délais, suivant les budgets impartis, sans réduire
l’envergure du projet : tout échec est susceptible de briser l’élan SOA. Naturellement, les projets critiques pour la mission de l’entreprise, dont les retards
risquent de compromettre certaines opérations métiers clé, doivent être évités.
Un bon projet pilote est un pari gagnant rapide qui ne nécessite qu’un faible
budget, et peut être finalisé dans un délai court. La portée d’un tel projet doit
donc être bien définie, sans défi technique à relever. En fait, un projet pilote
SOA n’est pas une démonstration technologique.
Gartner [Gartner 2006e] définit le Sweet Spot (ou zone la plus performante)
pour les candidats à un projet pilote SOA comme une zone cible positionnée
dans un quadrant fondé sur la complexité informatique par rapport à la valeur
métier, où la complexité informatique est moins élevée que dans la moyenne,
mais dont la valeur ajoutée pour l’entreprise est importante.
Réussite technique
Leadership
Démonstration
technique
convaincante
Risque élevé,
valeur ajoutée
importante
Complexité
informatique
Sweet Spot
C'est un début
Démontre la vision
Anecdotique
Visionnaire
Valeur métier
Source : Gartner (août 2006)
Figure 9.2 : Sweet Spot pour les candidats à un projet pilote SOA
La valeur métier est toujours directement liée aux « business pains », ces épines
dans le pied qui abondent dans toute entreprise. L’effort doit être quantifiable
par une ou deux valeurs numériques que chaque partie prenante doit pouvoir
comprendre et valider. Le retour sur investissement du projet sera calculé en
176
9 Comment démarrer la SOA ?
fonction de ces valeurs, mesurées avant et après le projet. La valeur métier du
projet doit être évaluée avec minutie : si elle est trop basse, le projet n’intéressera plus ses sponsors et sera considéré comme anecdotique, sans valeur.
Comment la SOA évite-t-elle la fraude dans les restaurants
Un centre de loisirs international avec hôtels et restaurants s’est trouvée confrontée
à un problème très particulier par rapport à l’un des processus métiers de ses établissements. Les clients qui achetaient un package hébergement+repas, se voyaient
remettre des tickets avec un identificateur à code barre qui donnaient accès aux
restaurants de la station. Un ticket par repas et par personne était prévu. Les tickets
étaient récupérés et enregistrés à l’entrée de chaque établissement par un serveur
muni d’un lecteur de codes barres.
Peu de temps après la mise en place de ce système, une consolidation des résultats
pour les différents restaurants du site a démontré que certains tickets étaient utilisés
deux fois le même jour. Le problème a persisté entraînant une perte de profit importante.
Après enquête, il s’est avéré que certains membres du personnel photocopiaient les
tickets avant de les donner aux clients et utilisaient ainsi les faux tickets pour obtenir
des repas gratuits.
La société a lancé un projet dont l’objet était le contrôle de l’utilisation des tickets en
temps réel. L’architecture du système d’information a été modifiée et un ensemble de
services partagés mis en place de manière à ce que le système d’enregistrement des
tickets de restaurant puisse refuser le ticket si celui-ci avait déjà été utilisé.
La fraude a disparu et la société n’a plus perdu d’argent.
Il existe plusieurs manières de choisir des projets :
•
En établissant la liste des projets métiers sur le point de démarrer et en
identifiant certains projets comme des candidats SOA (approche bottomup).
•
En identifiant des domaines applicatifs prometteurs pour la SOA et en
lançant les projets correspondants (approche bottom-up).
•
En déterminant les domaines d’activité les mieux adaptés à la SOA sur la
base d’un découpage par métier et en lançant les projets correspondants
(approche middle-out).
•
En générant une transformation vers une architecture d’entreprise basée
sur la SOA en fonction de la stratégie de l’entreprise et en réalisant cet
objectif par des projets (approche top-down).
177
SOA for Profit
Le choix qui vous convient le mieux est essentiellement conditionné par votre
culture d’entreprise et la manière dont les changements y sont déployés. Une
approche top-down sera privilégiée dans une structure très hiérarchisée alors
qu’une approche bottom-up sera considérée comme mieux adaptée dans un
environnement plus informel.
Le choix des projets capacitaires
Comme l’indique la Figure 9.1, vous pouvez également identifier des « projets
capacitaires » en plus des projets métiers. Ces projets dont destinés à la préparation de votre entreprise pour une mise en œuvre efficace et performante
de la SOA. Ils sont établis à partir du modèle de maturité SOA et concernent
l’amélioration des processus, en particulier dans le domaine de la gouvernance et de l’architecture d’entreprise, par la formation et la sensibilisation
du personnel ainsi que le choix d’une technologie appropriée.
Exemples de projets capacitaires :
• Description des rôles et des responsabilités par rapport au cycle de vie des services.
• Mise en place d’un centre d’excellence SOA.
• Mise en place d’un système de gestion des portefeuilles de services.
• Établissement de normes et directives pour la création de services. Un élément
essentiel à ce sujet : les règles de définition de la granularité d’un service.
• Définition des principes SOA comme éléments de l’architecture d’entreprise.
• Formation d’analystes métiers et d’ingénieurs logiciels.
• Choix et mise en œuvre d’un registre des services.
• Élaboration d’un schéma de développement pour l’assemblage des services.
• Organisation d’une tournée de présentation pour expliquer les concepts et la
valeur ajoutée de la SOA pour l’entreprise à divers groupes cibles.
• Création d’un ensemble de composants (pour gérer les actifs informatiques mais
aussi les processus métiers, des modèles ou des directives de conception, etc.).
La SOA aboutit à une infrastructure informatique plus générique. Au chapitre
4, nous avons vu que l’architecture de référence SOA comporte onze domaines pour lesquels des aides infrastructurelles sont nécessaires. Cette infra­
structure SOA générique s’appuie en partie sur des projets métiers et en
partie sur des projets de disponibilité. La mise en œuvre d’un ESB est l’exemple caractéristique d’un projet de ce type. La plupart des entreprise estiment
qu’il est très difficile d’établir un business case pour un ESB, voire de trouver
un sponsor dans le métier. Néanmoins, un ESB est essentiel comme outil de
178
9 Comment démarrer la SOA ?
transport et de routage pour la SOA. Comme le montre le modèle de maturité
SOA, il faut investir dans la technologie à un moment donné pour préparer
le terrain. Tout d’abord, les projets métiers et les projets de disponibilité vont
fournir les composants de l’architecture SOA générique ; mais au fil du temps,
ce sont principalement les projets métiers qui bénéficieront du fait qu’une
part croissante de l’infrastructure dont ils peuvent faire usage, est déjà en
place. Cela va considérablement accélérer les choses.
Enfin, la feuille de route SOA se compose de projets métiers et de projets capacitaires. Comme il est impossible de prévoir à l’avance tous les projets SOA, nous
vous conseillons d’établir une feuille de route pour une certaine période, de
préférence assez courte, d’environ six mois, mais sans excéder une année.
Ensuite, nous vous conseillons de revoir vos objectifs et d’effectuer une nouvelle
évaluation pour établir une autre feuille de route pour une période différente.
9.3 Les points d’entrée
L’utilisation de points d’entrée (Personnel, Informations, Processus, Réutilisation et Connectivité) donne une réponse à la question sur les domaines possibles de mise en œuvre de la SOA au sein d’une entreprise (IBM 2006e). Ces
points d’entrée décrivent les problèmes récurrents que l’on peut résoudre grâce
à la SOA. Un plan de projet peut être établi pour chacun des points d’entrée. Ce
plan n’est pas fondamentalement différent d’un autre projet : il faut un objectif
métier concret soutenu par un business case. Les points d’entrée sont importants
en partie parce qu’ils permettent de déterminer des objectifs clairs pour le projet SOA. Quel est le problème métier à résoudre en introduisant la SOA ?
En partenariat avec Mercer Management Consulting, IBM a étudié les pratiques émergentes parmi ses 1 900 clients SOA. Ces études ont mis en évidence
trois points de départ SOA orientés métiers : le Personnel, les Processus et
l’Information, et deux points de départ orientés informatique : la Connectivité
et la Réutilisation.
Une approche SOA orientée métiers commence par l’analyse de l’entreprise.
Le but est d’identifier les domaines qui bénéficieront le plus rapidement d’un
meilleur accès et d’une intégration améliorée pour les individus dans des
domaines d’activité critiques. Avec une approche de ce type, les entreprises
peuvent associer les projets informatiques aux besoins de l’entreprise, en
abordant directement les problèmes immédiats.
179
SOA for Profit
Utilisateurs
Processus
Information
Réutilisation
Connectivité
Figure 9.3 : Les cinq points d’entrée
Les points d’entrée aident les entreprises à mener une stratégie SOA au
mieux, en adoptant une approche basée sur le projet et en exigeant que chaque projet apporte une réelle valeur métier. De cette manière, chaque entreprise sera prête à optimiser les bénéfices d’une SOA, à comprendre les avantages liés aux composants modulaires et aux services web, à améliorer les
processus métiers et à exploiter les nouvelles opportunités d’amélioration.
L’approche commence par une étude des actifs fondamentaux de l’entreprise :
le Personnel, l’Information et les Processus d’un point de vue métiers. Le
contexte technique requis pour l’intégration du Personnel, des Informations
et des Processus sera apporté par les points d’entrée Connectivité et Réutilisation.
Dans les sections qui suivent, nous allons dresser de brefs descriptifs et donner des exemples pour chaque point d’entrée afin d’illustrer les véritables
engagements et les expériences des clients. Nous exprimerons notre vision
sur les défis à relever, les points d’entrée utilisés, en expliquant brièvement
la solution et les avantages pour l’entreprise. Avec toutes ces informations,
vous pourrez ainsi identifier certains de vos propres défis, ce qui vous indiquera la démarche à suivre.
180
9 Comment démarrer la SOA ?
Utilisateurs
Information
Connectivité
Processus
9.3.1 Collaboration centrée sur les utilisateurs
Réutilisation
Entamer le voyage par une approche SOA centrée sur le
métier commence par une analyse de l’entreprise. Cette dernière permettra
d’identifier les domaines qui réagiront le plus rapidement à toute amélioration de l’accès et de l’interaction des utilisateurs dans des domaines d’activité
critiques. Ce point d’entrée s’appuie sur une amélioration de la productivité
par la collaboration.
Les entreprises qui se concentrent sur la collaboration des utilisateurs, souhaitent améliorer leur productivité en donnant à leurs employés, à leurs
clients et à leurs partenaires la possibilité de créer un environnement personnalisé pour agir en interaction avec d’autres personnes et informations
dans le contexte des processus métiers. Cette approche conduit à des interactions entre individus et processus avec des niveaux de service cohérents.
Par où commencer ? Tout d’abord, prenez les projets pilotes ciblés qui donnent les éléments de base pour le développement de solutions (SOA), en
insistant sur l’interaction avec les utilisateurs au travers de portails et de
tableaux de bord. Dressez une liste des principaux processus métiers en
regroupant les informations pour faciliter les prises de décision. L’étape
suivante sera une gestion plus serrée des performances par l’intermédiaire
de tableaux de bord pilotés par des alarmes pour établir un lien avec un plus
grand nombre de processus.
L’efficacité opérationnelle, c’est-à-dire d’une part la capacité à innover de
façon immédiate, et d’autre part la productivité des utilisateurs sont des éléments clé de la compétitivité et de la croissance de l’entreprise. Actuellement,
les entreprises se trouvent confrontées à des applications basées sur des silos
et des informations qui empêchent toute collaboration efficace entre employés,
partenaires et clients. C’est en responsabilisant les personnes grâce à des
solutions orientées services que vous pourrez relever ces défis et établir les
fondements d’une productivité, d’une collaboration et d’une communication
meilleures.
Il est évident que les utilisateurs pilotent l’interaction avec les services SOA
qui exécutent les résultats. Par conséquent, il faut miser sur les hommes pour
réussir le voyage SOA.
181
SOA for Profit
Utiliser le point d’entrée utilisateurs peut aider à :
•
Accélérer la productivité
•
Réduire les coûts d’accès à une multitude de sources d’application et
d’information
•
Instaurer et améliorer la collaboration à l’intérieur et à l’extérieur de
l’entreprise
•
Réduire les délais de mise sur le marché, déployer de nouveaux services
•
Améliorer l’accès à l’orchestration et à la souplesse des processus.
En plus des autres points d’entrée (Processus, Information, Réutilisation et
Connectivité), ce point d’entrée peut faciliter les décisions en temps réel, les
collaborations dynamiques et l’exécution immédiate.
En bref, l’approche SOA par les utilisateurs conditionne la souplesse métier
et opérationnelle et améliore la productivité et la collaboration. Néanmoins,
la qualité se révèle à l’usage. Dans l’exemple qui suit, nous allons résumer un
cas pratique en utilisant les utilisateurs comme point de départ pour mettre
en évidence les avantages réels pour l’entreprise.
Collaboration centrée sur le personnel dans un groupement d’école
Introduction
Il s’agit ici d’un groupement important d’écoles publiques primaires, secondaires
et d’établissements de formation comptant des dizaines de milliers d’étudiants,
d’enseignants, d’administrateurs, d’entités publiques et de parents multilingues
(plus de 200 collèges de formation, universités, instituts techniques et établissements militaires).
Une étroite collaboration entre ces organisations, l’accès aux informations, les sources de données, la présentation de rapports et d’indicateurs de performances clé sont
des paramètres essentiels pour assurer une éducation de qualité aux étudiants.
Néanmoins, les établissements possédaient des sources de données majeures réparties sur plus de 300 environnements applicatifs en silos qui étaient mal intégrés, ne
correspondant à aucun standard technologique reconnu et exempts de toute ébauche
d’architecture. Leurs processus métiers et les environnements informatiques n’étaient
pas alignés, d’où une mauvaise collaboration et communication et un manque de
réutilisation des actifs existants pour réduire les coûts de développement.
182
9 Comment démarrer la SOA ?
Les enjeux métiers
Le défi à relever était de créer un point d’accès unique pour toutes les personnes
impliquées dans l’amélioration de la collaboration et de la communication, d’optimiser les performances des étudiants, d’accroître le niveau général, de faciliter l’accès
aux informations de plus de 2 000 administrateurs et de réagir rapidement aux déficiences conformément à la législation publique en vigueur pour les établissements
scolaires financés par des fonds publics. Sans les rapports exhaustifs de ces établissements, les financements sont en danger.
Le but était aussi d’améliorer l’alignement entre les processus métiers et l’environnement informatique à partir des actifs existants, reliés autant que possible par des
standards ouverts, indépendants des solutions propriétaires.
La solution
Après l’analyse des exigences métiers, fonctionnelles et non fonctionnelles, un
modèle SOA qui intégrait tous les environnements informatiques disparates dans un
portail basé sur les rôles, a été établi. Étudiants, enseignants, administrateurs,
­parents et organismes publics externes disposaient d’un accès illimité aux applications, informations et services.
Les 2 000 administrateurs optimisent l’environnement portail en assurant le suivi
des ressources des établissements, en élaborant des rapports et en surveillant la
présence, les diplômes et les évaluations des étudiants. Ils peuvent désormais établir
des corrélations entre les facteurs métiers, c’est-à-dire déterminer la somme d’argent
dépensée par étudiant, le score moyen par établissement, les cartes de présence,
etc.
Les enseignants peuvent accéder aux données sur les étudiants et les étudiants
accéder aux tâches attribuées à leurs classes, aux ressources et aux calendriers
divers et même communiquer avec leurs enseignants et camarades. L’environnement peut se décliner en plusieurs langues pour améliorer la communication.
Certaines des applications disparates ont été intégrées après une certaine subdivision (« componentization ») en utilisant des services web, en préservant les actifs
existants et en évitant tout blocage par des solutions propriétaires.
183
SOA for Profit
Les avantages
Les véritables avantages résident dans la collaboration entre les enseignants, les
étudiants, les administrateurs et les organismes externes. Cette approche dénote
une amélioration significative. Par ailleurs, les administrateurs peuvent désormais
générer des rapports en quelques minutes au lieu de plusieurs semaines, ce qui leur
permet de comprendre plus rapidement les problèmes de performance et de faire
preuve d’une plus grande réactivité à ces problèmes.
Les applications et les sources de données associées, autrefois séparées, sont désormais accessibles à partir d’une interface, ce qui améliore la vision des performances
réalisées à l’échelle d’un territoire et permet de développer les ressources de toutes
les parties prenantes.
Comme les résultats des étudiants peuvent faire l’objet d’un suivi, les scores aux tests
s’en trouvent améliorés, garantissant ainsi la conformité avec la législation publique.
Conséquence directe : les financements ne seront plus en danger.
Utilisateurs
Information
Connectivité
Processus
9.3.2 La gestion des processus métiers
Réutilisation
Les entreprises orientées vers la gestion des processus
métiers s’intéressent à l’aptitude à optimiser leurs processus, à se développer
rapidement au moment opportun et à surveiller l’efficacité des processus
modifiés. En conséquence, elles sont plus à même de réagir à l’évolution du
marché et de prendre les mesures qui s’imposent. Toutefois, toute entreprise
doit veiller à ce que les composants des processus soient entièrement réutilisables de manière à en garantir une reconfiguration rapide et performante.
Vos processus métiers vous permettent-ils de réagir rapidement aux conditions changeantes du marché ? C’est en rationalisant les processus que vous
pourrez aligner les services informatiques sur les objectifs de l’entreprise et
réduire la complexité des processus de conception.
Pour commencer, modélisez un processus non performant, supprimez les
goulets d’étranglement puis simulez et déployez le processus optimisé. L’étape
suivante pourrait consister à créer des liaisons souples entre les multiples
processus de l’entreprise et à établir une interface entre les clients, les fournisseurs et les partenaires. Enfin, surveillez le processus en fonction d’indicateurs de performance clé adaptés et suivez les performances.
184
9 Comment démarrer la SOA ?
Optimiser la SOA en s’appuyant sur le point d’entrée du processus peut aider à :
•
Accroître la collaboration avec les partenaires et les fournisseurs.
•
Accélérer les délais de mise sur le marché.
•
Réagir rapidement aux défis métiers et agir en conséquence.
•
Mettre en œuvre plus rapidement de nouveaux processus.
•
Mieux réagir aux règles de conformité.
•
Optimiser le retour sur investissement.
Gestion des processus métiers chez un fabricant de motos
Introduction
Un fabricant de motos reconnu et respecté au niveau international compte un nombre
important de propriétaires enthousiastes qui souhaitent conserver leur propre identité. C’est une société dynamique qui tente de développer son portefeuille de produits
de plusieurs manières ; elle réagit à la demande du marché, prend en compte les
exigences spécifiques à sa clientèle régionale et étudie les possibilités de développement de l’activité sur le marché.
La société a établi de bonnes relations avec ses fournisseurs, agents, clients et investisseurs. De plus, elle a bien mesuré l’importance réelle du marketing et propose des
services spécialisés pour ses produits.
Au fil des années, l’informatique est devenue très importante, non seulement pour le
soutien des processus métiers, mais aussi comme un élément différenciateur qui
apporte un plus pour son réseau d’agents et sa clientèle.
Les enjeux métiers
La société est sensibilisée à l’importance de l’innovation du business model qui
peut permettre de réduire les coûts et d’améliorer la rentabilité. Sur un marché
actuel hautement concurrentiel, elle a besoin d’un système financier souple et agile
pour pouvoir réagir rapidement au bon déroulement d’une campagne de
­marketing.
Néanmoins, l’architecture applicative était composée d’éléments fortement couplés
utilisant des technologies obsolètes. Il n’existait aucune chorégraphie intégrée entre
les demandes de crédit, les autorisations de crédit et l’origine des prêts. Changer les
fonctionnalités au sein d’applications distinctes requiert beaucoup d’argent, de temps
et d’efforts, sans pour autant garantir un réel résultat par rapport aux demandes liées
aux exigences des programmes de promotion. De fait, la société perdait du terrain,
d’où la nécessité d’apporter une solution rapide.
185
SOA for Profit
La solution
La société s’est attaquée au modèle architectural du domaine financier d’un point de
vue métier en établissant des modèles de processus pour des packages financiers. Cette
démarche lui a permis de moderniser ses processus pour assurer le soutien et la promotion des plans financiers auprès des commerces de détail, tels que ses agents.
Le domaine applicatif a été restructuré conformément aux directives et principes SOA.
De plus, la société a utilisé une SOA pour défaire les points d’intégration câblés en
dur dans le domaine applicatif et basculer vers des services désormais indépendants
et faiblement couplés.
En conséquence, le domaine financier est passé en client léger et l’application exposant le processus d’approbation des crédits peut désormais proposer de nouveaux
programmes financiers nécessaires pour pouvoir réagir rapidement aux exigences du
marché. Les fonctionnalités nouvelles et existantes peuvent être modifiées rapidement, sans interférer avec les composants d’autres services.
Les avantages
Les améliorations obtenues ont été les suivantes :
• Les programmes financiers peuvent désormais être associés pour un coût moindre
aux promotions de marketing entreprises à la volée.
• De nouveaux modèles peuvent être proposés plus rapidement sur le marché au
moment opportun.
• Les services ne sont modifiés que dans les cas nécessaires, sans affecter toutes
les autres fonctionnalités.
• Le service clients s’en trouve amélioré grâce à un développement approprié des
stratégies de financement plus rapides, en totale adéquation avec les besoins de
la clientèle.
Utilisateurs
Information
Connectivité
Processus
Réutilisation
9.3.3 L’information : un service
L’utilisation des informations en tant que service est un
point d’entrée dans l’architecture SOA qui donne accès aux sources de données complexes et hétérogènes d’une entreprise en tant que services réutilisables. Ces services peuvent être accessibles au sein d’une entreprise ou dans
une chaîne de valeur. Les entreprises sensibilisées par l’accès à l’information
en tant que service sont très intéressées par la possibilité d’améliorer leur
vision de l’état de l’entreprise, en réduisant les risques grâce à des services
d’information sécurisés, proposés en ligne et en fonction du contexte.
186
9 Comment démarrer la SOA ?
Mais à mesure que l’information devient un élément clé pour chaque entreprise, il faut éviter les redondances ou contradictions car les utilisateurs doivent pouvoir « se fier » aux sources. En empruntant ce point d’entrée, vous
pourrez améliorer la capacité et la cohérence de l’information et mettre fin
aux traditionnelles barrières du partage de l’information.
Avez-vous une bonne connaissance des sources d’information de votre entreprise ? Connaissez-vous la valeur ajoutée exacte de l’information pour votre
entreprise et de leurs relations ? Il est temps de considérer l’information
comme un service, en veillant à la cohérence des définitions, du packaging, à
la gouvernance des données métiers sensibles, en vue de pouvoir proposer
des services d’information réutilisables dans vos processus métiers. Avec une
telle démarche, vous bénéficierez d’une plus grande souplesse tout en améliorant la productivité de l’informatique car les services pourront être maintenus de manière indépendante.
Vous pouvez commencer par identifier et étudier les sources d’information,
les relations entre les informations et le contexte métier. L’étape suivante
consistera à accroître le volume et la portée des informations fournies en tant
que service dans tout les processus internes et externes. Ce point d’entrée
peut constituer une valeur ajoutée SOA par l’information de différentes
manières :
•
En augmentant l’agilité de l’entreprise, en proposant des services
d’information réutilisables, en intégrant les informations structurées et
non structurées qui peuvent être associées au sein d’applications, de processus métiers et/ou de portails. Par cette approche, les coûts liés à l’accès
et à la transformation des données pourront être réduits ;
•
En rendant les données accessibles ; vous disposerez d’une vision
homogène de l’activité avec une intégration claire des données analytiques
pour améliorer la transparence et la vision métier ;
•
En réduisant les coûts et les risques associés à toute rationalisation et migration d’infrastructures. À cette fin, il faut séparer les informations des environnements applicatifs en silos préalablement évoqués. Réduisez les risques
par des analyses en ligne, en veillant au caractère vérifiable des données et
par les initiatives de conformité d’organismes internes et externes.
Si vous entamez des projets séparés à partir des points d’entrée Utilisateurs,
Processus ou Information, vous en tirerez des avantages tout en optimisant
le retour sur investissement. Néanmoins, c’est en combinant les trois points
187
SOA for Profit
d’entrée SOA d’un point de vue métier dans le contexte d’un effort bien
orchestré que vous obtiendrez les résultats les plus rapides.
Néanmoins, sans l’informatique, il est impossible d’intégrer les utilisateurs, les
Processus et les Informations au sein d’une entreprise. L’expérience montre
qu’il faut une infrastructure orientée services composée d’une couche de communication auto-sécurisée, auto-réparatrice, auto-configurante et auto-optimisante standardisée, qui permette la transformation d’une infrastructure verticale, en silos, orientée applications vers une approche plus horizontale.
L’information comme service chez un opérateur de télécommunications
Introduction
Grâce à plusieurs millions de clients connectés, ce grand opérateur de télécommunications propose des ensembles complets et innovants de services de communication
à des particuliers et des professionnels dans le monde entier.
La société propose à ses clients des solutions simples, adaptées à leurs besoins,
notamment des services téléphoniques, sans fil, Internet à haut débit, communication
satellite pour la télévision numérique et Voix sur IP. En plus, elle propose des solutions
autour des technologies de l’information et de la communication à de grands groupes, de petites et moyennes entreprises et des organismes publics.
Les enjeux métiers
La société devait réagir aux pressions externes liées à la réglementation et à la concurrence sur le marché des télécommunications. Compte tenu de la forte concurrence, elle
devait améliorer la compréhension de sa clientèle et ses relations avec cette dernière.
Étant donné que les clients ne sont pas très fidèles dans le secteur des télécommunications, elle devait également proposer des produits innovants, ce qui l’a contrainte à
passer d’une perspective centrée sur le produit à une perspective centrée sur le client.
Pour réussir dans cette démarche, elle avait besoin d’identifier les clients les plus rentables, d’avoir une vision unique de la clientèle à travers les applications et les secteurs
d’activité et d’améliorer autant que possible la fidélisation de ses clients.
La solution
Un modèle de données normalisé, éprouvé, pour l’ensemble de la société a constitué un
composant de construction essentiel et le point de départ du voyage SOA. Pour résoudre
le problème, un nouveau système de gestion des clients a été mis en place à partir d’une
technologie d’intégration des données de référence. Ce système a été mis en phase avec
les principes de qualité issus de son entrepôt de données existant, pour obtenir ainsi une
vue globale unique des clients au niveau de tous les systèmes opérationnels.
188
9 Comment démarrer la SOA ?
Les avantages
En mettant sur pied une solution à partir de ce point d’entrée SOA, la société a
­amélioré sa stratégie de marketing ciblée car elle est parvenue à identifier et à rattacher les clients à des canaux différents. Désormais, elle peut identifier et classer
rapidement ses clients pour obtenir des offres qui correspondent exactement à leur
segment et profil. Par ailleurs, les changements au niveau des réglementations nationales peuvent désormais être traités plus rapidement.
Conséquence directe : une fidélité accrue de sa clientèle grâce à la richesse des
offres et un nombre de « mauvaises surprises » largement réduit. Les coûts admi­
nistratifs ont diminué grâce à une amélioration du rendement. Par ailleurs, la capa­
cité à réutiliser les informations en tant que service a entraîné une réduction notable
des coûts d’interface (seulement 2,5 % du coût par rapport à la première interface
installée).
Utilisateurs
Information
Connectivité
Processus
9.3.4 Connectivité
Réutilisation
Le point d’entrée Connectivité aide l’entreprise à intégrer
les points d’entrée SOA orientés métiers. Dans le passé, la connectivité a
toujours été une exigence essentielle ; elle le sera encore plus dans le cadre
des futures mises en œuvre de la SOA. Elle est destinée à simplifier l’environnement informatique en proposant des méthodes de connexion plus sûres,
fiables et scalables à l’intérieur et à l’extérieur de l’entreprise. Elle doit relier
les individus, les informations et les processus par l’intermédiaire de flux de
messages de données partout, à tout moment et de n’importe quelle source.
C’est à ce niveau que le domaine de connectivité constitue véritablement une
valeur ajoutée. En apportant sa valeur métier, la connectivité est aussi un
composant fondamental pour toutes les initiatives SOA dans un futur
­proche.
La mise en œuvre d’un ESB pourrait faire partie du point d’entrée Connectivité. C’est un ensemble de middleware qui unifie et connecte les services, les
applications et les ressources au sein d’une entreprise. En d’autres termes,
c’est le framework à partir duquel sont exposées les capacités des applications
d’une entreprise pour être réutilisées par d’autres applications au sein de
l’entreprise et même au-delà.
189
SOA for Profit
Quelle est la valeur de la connectivité des services pour votre entreprise ? Ce
concept peut ouvrir des portes aux clients, aux partenaires et aux fournisseurs
en leur offrant un éventail de méthodes d’interaction avec votre entreprise. Avec
la connectivité, vous pourrez proposer une logique de présentation cohérente,
indépendamment du canal commercial choisi. La collaboration en sera améliorée par l’intégration interne et externe des entités et/ou des divisions.
En bref, la connectivité peut aider à :
•
Intégrer les individus, les processus et les informations ;
•
Mettre une entreprise en ligne avec la croissance du marché ;
•
Instaurer des relations de confiance avec les clients, les fournisseurs et les
partenaires ;
•
Créer un domaine de connexion scalable, sécurisé et disponible à partir de
standards ouverts.
La connectivité chez un fournisseur de technologies sanitaires
Introduction
Fabriquer des installations sanitaires à la fois fonctionnelles et esthétiques constitue le
principal objectif de ce fournisseur de technologies européen qui est également le
premier exportateur de robinets, baignoires et autres accessoires commerciaux et appareils électroménagers dans le monde. La société propose des produits et des services
complémentaires dans plus de cent pays par l’intermédiaire de son réseau d’agents
répartis dans le monde entier. Les ventes à l’export représentent environ 80 % du chiffre d’affaires total et sont donc essentielles pour le développement de l’activité.
Les enjeux métiers
Sur ce créneau, les délais de livraison des nouveaux produits sont très importants car
la concurrence fait rage. Un démarrage en tête entraînera en principe une augmentation des ventes. Néanmoins, l’environnement applicatif qui encadre les opérations,
les processus métiers et les systèmes logistiques du site existant est mal intégré. Le
développement spécifique d’applications nouvelles ou d’évolutions ralentit les délais
de mise sur le marché et augmente les coûts.
En regroupant les exigences propres à un nouveau système ERP (Enterprise Resource
Planning), la société a dû imaginer comment échanger les données entre les nouveaux
modules ERP et plusieurs applications patrimoniales (applications de gestion de la
production et des taxes d’exportation, de suivi des livraisons, systèmes de catalogues
produits et de facturation, logiciels de gestion des stocks, de la logistique et des codes
barres).
190
9 Comment démarrer la SOA ?
Au total, la société a identifié 14 interfaces à créer. Comme le projet devait être
fina­lisé assez rapidement, il fallait déterminer s’il était plus rentable de procéder à
une intégration par un développement spécifique, point à point ou de faire l’acquisition d’un package de solutions conçues pour une intégration rapide et une cohérence continue des processus métiers. Il fallait aussi éviter tout blocage par un
fournisseur.
La solution
La production, les processus métiers et les systèmes logistiques existants ont été
intégrés dans un environnement ESB permettant l’intégration de systèmes et de
bases de données Back end. En acheminant et en traitant de 5 000 à 25 000 messages par jour, la solution ESB assure un échange global d’informations au travers
d’une chaîne de services entre des Front end et Back end faiblement couplés.
Les avantages
Les véritables avantages ont été une intégration améliorée de l’activité, des utilisateurs et des processus et un alignement métier total, ainsi que la croissance du chiffre
d’affaires à l’export.
Le temps d’intégration moyen a pu être diminué de 84 % (2 à 4 semaines contre 6
mois). Par ailleurs, les délais et les coûts d’intégration des applications patrimoniales
avec les nouveaux modèles ERP ont été réduits par rapport à ceux d’une technique
d’intégration par développement spécifique, point à point.
La solution a aussi permis des transferts de données plus fiables et très perfor­
mants : l’exposition de services par des systèmes patrimoniaux permet la réutilisation des actifs à la demande. Par cette approche, la société estime que son
système informatique peut proposer un nouveau service en ligne dans un délai
de deux à quatre semaines. Cela améliorera considérablement les délais de mise
sur le marché.
Utilisateurs
Information
Connectivité
Processus
9.3.5 Réutilisation
Réutilisation
Créer des composants réutilisables signifie créer des fonctions ou un ensemble spécifique de fonctions, et proposer des interfaces standards pouvant être utilisées et réutilisées à de multiples reprises.
L’objectif principal de chaque mise en œuvre de la SOA est de maximiser
les opportunités de réutilisation pour chaque couche informatique existante. Pour ce faire, il faut repenser les capacités redondantes, d’exposer
191
SOA for Profit
et de promouvoir les fonctionnalités communes et de concevoir de nouvelles fonctions métiers comme des services réutilisables. Ceci ne peut être
fait qu’en introduisant une gouvernance forte, basée sur des indicateurs
qui favorisent la réutilisation afin de réduire les coûts informatiques et les
délais de mise sur le marché en vue de gagner du terrain sur la concurrence.
Il est essentiel de diminuer les coûts, de réduire la durée des cycles de développement et d’élargir l’accès à des applications de base en offrant des opportunités de réutilisation. Grâce à ces opportunités, les utilisateurs bénéficient
d’une certaine souplesse car la durée des cycles est inférieure et les processus
redondants sont éliminés.
Au départ, vous pouvez gérer des portefeuilles afin de déterminer les actifs
informatiques requis pour exploiter l’entreprise. Ensuite, il faut identifier les
principaux actifs informatiques de haute valeur déjà en place et permettre
leur réutilisation. Les autres besoins peuvent être couverts par de nouveaux
services. Avec cette approche, l’utilisation d’un registre et d’un référentiel de
services garantissant un accès centralisé et le contrôle des nouveaux actifs
réutilisables sera également bénéfique.
Quelle valeur ajoutée apporte le concept de réutilisation dans une entreprise ?
•
Il réduit les coûts de maintenance en éliminant les systèmes redondants.
•
Il réduit le volume de code à produire dans le cadre d’initiatives métiers.
•
Le désengagement de composants informatiques existants est moins
important.
•
Les nouvelles fonctions métiers peuvent être créées par des fonctions
composites à partir des applications existantes.
La réutilisation dans une grande banque
Introduction
Une grande banque propose ses services à une clientèle diversifiée, allant de grands
groupes aux particuliers en passant par les petites et moyennes entreprises. Les 9 000
salariés proposent des produits et des services financiers par l’intermédiaire d’un
réseau national constitué de près de 250 agences, avec plus de 1 000 distributeurs
automatiques et des canaux de distribution électroniques supplémentaires.
192
9 Comment démarrer la SOA ?
Les enjeux métiers
Partout dans le monde, les banques estiment qu’elles doivent améliorer leur façon
de travailler pour survivre sur des marchés fortement concurrentiels. Les vieilles
méthodes ne marchent plus. Les banques sont en concurrence avec des com­
pagnies d’assurances et des sociétés de courtage qui proposent également des
ser­vices bancaires. Les banques internationales partent à la conquête d’une
­clientèle locale. Elles se différencient de leurs concurrents par la recherche des
moyens permettant de répondre au mieux aux besoins de leurs clients. En effet,
cette clientèle choisit des banques qui proposent de nouveaux services et un plus
grand confort. Pour améliorer son positionnement, cette grande banque devait
prendre des mesures.
L’accent a été mis sur une simplification des transactions par des canaux multiples
avec une réutilisation aussi fréquente que possible des actifs et des applications en
place (GRC, web et autres).
Par ailleurs, il fallait améliorer la compétitivité en mettant en place une infrastructure
plus rapide, simplifiée et plus flexible pour soutenir les nouveaux processus métiers
visant à améliorer le service clients.
La solution
À l’issue d’une analyse des exigences métiers clairement définies (fonctionnelles et
non fonctionnelles), la méthode a consisté à reprendre les fonctions applicatives
existantes, puis à les transformer en services métiers en utilisant le format XML. À
l’aide d’outils de simulation de modèles métiers et fonctionnels, certains processus
métiers ont été redéfinis et les actifs existants réutilisés autant que possible. Grâce à
cette démarche, d’anciens développements ont été réutilisés et les temps de développement réduits de 40 %.
Les applications plus anciennes, comme les services bancaires par Internet, étaient
toujours conformes aux exigences de performance; elles accédaient néanmoins à des
sources de données identiques, telles que la GRC, l’ERP et les systèmes bancaires
centraux. Avec sa nouvelle architecture SOA, la banque a pu mettre en place des
services réutilisables proposés par de nouvelles applications (comme l’évaluation des
risques d’un crédit et l’identité des transactions) sans affecter son architecture web
existante.
Les avantages
Par une réutilisation des actifs existants et une optimisation de l’environnement
­informatique, le taux moyen des transactions mensuelles de la banque a augmenté
de 300 % grâce à un accès simplifié proposé à des clients par des canaux multiples.
193
SOA for Profit
La banque a pu mieux s’adapter aux évolutions du marché et aux exigences de ses
clients. L’intimité avec les clients a été accrue de manière significative par une
­amélioration des services clients.
La réutilisation de presque 51 % des services existants a entraîné une réduction des
temps de développement des applications et des coûts de maintenance, et ainsi des
économies de l’ordre de plusieurs millions de dollars. Résultat : une meilleure ­réactivité
face à l’évolution des exigences métiers grâce à une infrastructure applicative souple.
Le personnel informatique de la banque a ainsi pu se consacrer à d’autres exigences
des lignes de métier. Les services dans leur globalité en ont été améliorés et la nécessité de faire appel à un personnel supplémentaire et de le former s’en est trouvée
réduite.
9.4 Synthèse
En bref, comment dois-je accomplir mon voyage SOA et quels éléments ont
du sens pour mon entreprise ? Comme nous l’avons déjà expliqué, il n’existe
aucune méthode standard ; tout dépend de vos priorités, de l’envergure de
votre projet et de vos objectifs. Néanmoins, si vous adoptez une approche SOA
orientée métiers, vous aiderez votre entreprise à s’assurer que ses investissements restent concentrés sur les domaines qui présentent le plus d’intérêt
pour votre activité. Commencez par le dialogue stratégique et établissez une
feuille de route SOA. Cela vous aidera à déterminer vos priorités et objectifs
pour le voyage SOA. Certains projets métiers et capacitaires constituent les
éléments clé de cette feuille de route. Les points d’entrée vous aideront à
trouver les bons projets métiers par lesquels commencer, en identifiant les
avantages métiers qui y sont associés.
Comme il est impossible de prévoir tous les projets SOA, nous vous conseillons
d’établir une feuille de route pour une période spécifique, de préférence de
6 à 12 mois. Ensuite, vous pouvez à nouveau réfléchir, vérifier vos objectifs,
effectuer une évaluation à l’aide du modèle de maturité SOA, puis établir une
feuille de route pour une nouvelle période.
194
10 Comment arriver à bon port
10.1 Présentation
Comme nous l’avons vu dans les précédents chapitres, la mise en œuvre de la
SOA ne doit pas être sous-estimée. La réelle complexité des services et des
processus métiers à créer, exposer, mettre en œuvre ou utiliser par l’ensemble
des tiers internes ou externes peut constituer un défi majeur. En fait, ce parcours est semé d’embûches. Si vous gérez correctement les risques, vous pourrez peut-être vous en sortir, mais sans parvenir forcément au but que vous
vous étiez fixé. Peut-être y parviendrez vous malgré tout, mais quelques semaines voire quelques mois trop tard ou à un coût prohibitif.
Citons deux types de risques qui jalonnent votre voyage vers la SOA :
•
Les risques liés à la méthode employée pour parvenir à destination. Ces
risques peuvent être les suivants : « la mise en œuvre doit être effective à
compter du premier janvier » ; ou « les spécifications sont fournies en
retard », « les testeurs expérimentés ne sont pas disponibles » ou
« l’infrastructure n’est pas prête à temps ».
•
Les risques liés à la destination du voyage en tant que tel, en d’autres
termes les risques SOA.
Que se passera-t-il si cette architecture ne donne aucun résultat ou qu’elle
comporte des erreurs ? Il en résulterait des risques considérables pour l’activité de l’entreprise : coûts élevés de réadaptation, perte de productivité,
mauvaise image de marque ou atteinte à la réputation. Les conséquences
peuvent être, par exemple, des demandes d’indemnisation et la perte de compétitivité provoquée par une disponibilité retardée d’un nouveau produit ou
service (entraînant une perte de chiffre d’affaires).
Avant d’entamer le voyage vers la SOA, toute entreprise doit clairement se
demander si elle remplit bien toutes les exigences exprimées. Les services,
les sous-systèmes, les objets et l’architecture impliqués par les exigences ontils été étudiés suffisamment en profondeur ? Des tests d’efficacité, de performance et de sécurité, par exemple, ont-ils été réalisés en plus d’un contrôle
fonctionnel ? A-t-il été clairement établi si la SOA possédait les caractéris­
195
SOA for Profit
tiques et les fonctions requises pour satisfaire aux besoins explicites ou implicites (même si plus complexes) ? À noter qu’une chose qui semble couler de
source pour une personne, peut s’avérer une révélation pour une autre.
La vraie question est la suivante : quels sont les risques encourus et quelles
mesures doivent être prises pour éliminer ces risques ? Pour éviter que les
réponses à ces questions cruciales n’interviennent que lorsque vous en serez
déjà à la phase opérationnelle de la SOA, il faut prévoir une méthode de test
fiable avant de passer à l’action. Cela nécessite la mise en place d’une approche structurée par rapport au test, à l’organisation et à l’infrastructure qui
permette d’obtenir (de manière maîtrisée) une vision continue de l’état de la
SOA et des risques qui y sont associés. Ces défis sont assez différents du processus « traditionnel » de développement de logiciels et peuvent se résumer
en quatre principes. Nous allons vous présenter maintenant ces principes,
puis les expliquer de manière plus détaillée dans le chapitre suivant.
Qui est propriétaire, qui paie ?
Un service utilisé dans plusieurs services ou processus métiers doit être
d’une qualité irréprochable. Pour tester ce service, vous devez déployer un
effort supplémentaire. La question est de savoir qui va payer : le département qui propose le service ou le département qui l’utilise ? Cela nous
amène donc à la question de savoir qui bénéficiera le plus d’un service de
haute qualité et qui est prêt à le payer. Pour répondre à ces questions, il faut
savoir que les tests évitent les coûts de réadaptation (élevés) et les dommages consécutifs sur l’architecture SOA dans son ensemble. En effet, les
défauts sont identifiés et supprimés pendant le processus de développement
du système. Cette approche ajoute également une certaine crédibilité au
projet SOA dans son ensemble.
Quand tester quel service ?
Dans le contexte SOA, les services sont associés les uns aux autres de manière
structurée. Un service peut par exemple donner accès à un autre service, et
inversement. Cela signifie souvent que pour tester un service, vous avez
besoin d’un autre service. Mais ce service est-il déjà disponible, testé et suffisamment bon ? Lorsque vous testez une architecture SOA, vous devez aligner la planification de ce test avec celle du développement ou de la mise en
œuvre des services. En effet, vous ne pouvez rien tester avant que le service
requis n’ait été développé de manière appropriée.
196
10 Comment arriver à bon port
Comment tester un service ?
La plupart des services SOA ne possèdent aucune interface utilisateur. En
général, les « testeurs » sont habitués à travailler à partir d’une interface. Ces
deux faits combinés constituent un problème majeur auquel il faudra trouver
une solution. Il faut quelque chose pour communiquer avec le service.
Qui dit beaucoup de services, dit beaucoup de tests
Avec tous ces services, le risque est que l’équipe chargée des tests veuille tout
tester à tous les niveaux. Mais il existe déjà beaucoup de niveaux et de types
de tests, comme les tests de prototypes, d’unités, d’intégration d’unités, de
régression d’unités, de services, d’intégration de services, de régression de
services, de performances des services, de systèmes, et d’intégration des systèmes. On ne peut pas tout tester. Vous devez donc faire un choix en fonction
des risques et des priorités.
À cette fin, vous avez besoin d’une approche structurée qui :
•
Organise votre démarche afin que vous sachiez exactement quelles sont
les choses à faire, par qui, quand et dans quel ordre ?
•
Couvre l’ensemble du périmètre et décrive l’ensemble des activités associées.
•
Constitue une base solide pour l’avenir, ce qui vous évitera de devoir réinventer la roue.
•
Gère les activités de test en fonction du temps, du budget et de la qualité
disponibles.
TMap est l’approche test de Sogeti reconnue à l’échelle internationale [Koomen 2006]. On peut résumer cette approche de la façon suivante :
1. TMap est basée sur une approche BDTM (Business-driven Test Management – pilotage des tests par les objectifs métiers).
2. TMap décrit un processus de test structuré.
. TMap contient un ensemble d’outils complet.
. TMap est une méthode de test adaptative.
Vous pouvez relier directement le premier point au fait que le business case
informatique est essentiel pour les entreprises. L’approche BDTM donne le
contenu qui gère ce sujet dans TMap ; on peut donc la considérer comme
l’élément moteur du processus de test structuré TMap (second point essentiel). Le modèle du cycle de vie TMap est utilisé dans la description du processus de test. Par ailleurs, il faut mettre en place plusieurs aspects relevant
du domaine des infrastructures, de la technique et de l’organisation pour
197
SOA for Profit
mener à bien ce processus. TMap fournit beaucoup d’informations pratiques
à ce sujet, sous la forme d’exemples, de check-lists, de descriptions techniques, de procédures, de structures organisationnelles, d’environnements et
d’outils de tests (troisième point essentiel). TMap est également un outil flexible qui peut s’installer dans différents contextes de développement : pour le
développement et la maintenance d’un système, pour un développement spécifique ou un package acheté et pour l’externalisation (de certaines parties)
du processus de test. En d’autres termes, TMap est une méthode adaptative
(quatrième paramètre essentiel).
Méthode
Guide pour achever
le processus de test
flex
ible
adaptative
Gestion des tests par
les objectifs
métiers
Techniques
Infrastructure
Entreprise
Figure 10.1 : Modélisation des points essentiels de TMap
10.2 Comment définir une stratégie de tests SOA ?
Comment mettre en place des tests qui couvrent les risques majeurs liés à la
mise en œuvre de la SOA ? Et plus encore, quels sont ces risques ? Cette
démarche est réalisée dans le cadre d’un processus en plusieurs étapes ; elle
nécessite l’engagement des testeurs, des utilisateurs du ou des services et des
autres parties prenantes.
La solution est de tester uniquement ce qu’il faut, et juste assez pour couvrir
le risque. Les tests sont effectués sur la base de cas de test, de check-lists et
d’autres moyens similaires. Mais de quel type de test s’agit-il ? Pour être utiles, les tests doivent couvrir toutes les caractéristiques et parties d’un service
198
10 Comment arriver à bon port
(ou de combinaisons de services) qui présentent un risque si le service ne
fonctionne pas correctement ensuite en situation de production. Cela signifie
que vous devez avoir pris en compte plusieurs paramètres avant de commencer. En d’autres termes, vous devez déjà avoir déterminé les éléments du
service à ne pas tester, ainsi que ceux qui devront être testés, en définissant
la méthode et l’étendue du test. Mais qu’est-ce qui détermine ces paramètres ? Pourquoi ne pas tester tous les éléments du service avec autant de
minutie que possible ? Si une entreprise possédait des ressources illimitées,
une solution pourrait être de tout tester aussi soigneusement que possible.
Mais naturellement, dans la pratique, une entreprise ne possède jamais les
ressources suffisantes; autrement dit, il vous incombe de déterminer quels
sont les éléments à tester et dans quelle mesure. L’un des sept concepts SOA
de base est d’ordre économique, les choix en découlant étant aussi économiques. Si vous investissez dans la SOA, vous souhaiterez savoir quels en seront
les bénéfices. La théorie de la gouvernance informatique guide les projets
SOA sur la base de quatre aspects à savoir : le résultat, le risque, le temps et le
coût. À titre d’exemple, une entreprise peut estimer qu’il est plus intéressant,
en termes d’investissement, de commencer par un projet SOA à haut risque
susceptible de donner d’excellents résultats, que par un projet SOA très peu
risqué, mais dont les bénéfices dépassent à peine les coûts.
Pendant les tests SOA, cette justification économique de l’informatique joue
un rôle essentiel et doit se refléter dans le processus. Pour réussir un projet,
il faut que le processus de test soit en harmonie avec les quatre aspects de
gouvernance informatique que nous avons déjà évoqués. Le rapport entre ces
aspects s’établit suivant l’approche BDTM. Nous allons donc décrire cette
approche en insistant en particulier sur les tests SOA.
10.3 Les différentes étapes de l’approche BDTM
Pour comprendre l’approche BDTM (Business-driven Test Management – pilotage des tests par les objectifs métiers), il ne faut jamais perdre de vue l’objectif final : une évaluation de la qualité et une préconisation sur les risques
pour le service concerné. Comme tout ne peut pas être testé, une évaluation
correcte n’est envisageable que si l’effort fourni est bien réparti en termes de
temps et d’argent, de la façon la mieux appropriée entre les éléments et les
caractéristiques du service à tester. La personne qui prendra la décision
ultime sur la répartition entre le temps et les coûts à consacrer par rapport
aux résultats à atteindre et aux risques à vérifier par des tests est le client.
199
SOA for Profit
Pour que cette décision soit fondée, le responsable du test doit par conséquent
impliquer le client dans le processus et fournir les bonnes informations. Dans
la Figure 10.2, le client joue ainsi un rôle central.
Objectifs du test :
Facteurs de réussite critiques
Demandes d’évolution
Exigences
Métiers, etc.
Client
Résultats, Risques,
Temps et Argent
1. Analyse des risques d'un produit
2. Stratégie:
a. choisir les niveaux de test
b. choisir un test rapide/approfondi
c. évaluer les forces/élaborer un planning
d. attribuer des techniques de test
3. Tests réels :
spécifier les cas de test,
effectuer les tests, etc.
Figure 10.2 : Étapes de l’approche BDTM
Nous allons maintenant expliquer dans les trois sections qui suivent, les étapes qui constituent l’approche BDTM.
10.3.1 L’analyse des risques d’un produit
Dans l’analyse des risques d’un produit, le service ou le processus métiers à
tester est analysé en vue d’élaborer une vision commune, à la fois pour le
responsable du test et les autres parties prenantes, de toutes les caractéristiques et parties du ou des services présentant des risques plus ou moins élevés
ou du processus métiers à tester. Le but est de pouvoir déterminer le niveau
de test requis par rapport à cette vision.
Dans une analyse de ce type, l’accent est mis sur les risques liés au produit,
c’est-à-dire sur le risque encouru par l’entreprise si le produit ne possède pas
la qualité escomptée. Il faut également savoir si ce risque est faible, moyen ou
(très) élevé.
200
10 Comment arriver à bon port
On peut définir un risque comme la probabilité de dysfonctionnement du
produit en relation avec les dommages prévisibles dans un tel cas.
Dans la pratique, voici une liste non exhaustive des risques spécifiques aux
environnements SOA :
•
La qualité d’un service est insuffisante pour un ou plusieurs des autres
services ou processus métiers qui l’utilisent, ce qui donne un ensemble
défectueux de services dont l’origine des dysfonctionnements est difficile
à identifier.
•
Le service peut être de qualité suffisante pour le processus métiers auquel
il était initialement destiné ; mais sa qualité est-elle suffisante pour les
autres processus ?
•
Les services ne sont pas conformes aux standards architecturaux, d’où une
informatique rigide avec de nombreux services qui se recoupent.
•
Une importance trop grande est accordée à l’aspect fonctionnel, sans que
les autres exigences ne soient prises en compte, ce qui donne par exemple,
des performances insuffisantes ou un manque de sécurité.
•
Les services et processus métiers ne sont pas suffisamment alignés, d’où
des processus inefficaces.
Ces risques dépendent également de la maturité de la mise en œuvre de la
SOA, depuis le simple ESB qui relie des applications patrimoniales, jusqu’au
concept SOA bien abouti, avec des services métiers soutenant les processus
métiers.
Évaluer les risques peut être un vrai casse-tête. Vous devez connaître les
risques relatifs à l’architecture, aux différents services techniques et métiers,
aux processus métiers et les dommages possibles ou les probabilités de
défaillance. Le responsable des tests ne possède pas ces connaissances, ou
alors seulement de façon limitée. De plus, les connaissances sont généralement réparties entre plusieurs entités ou individus. D’où la nécessité pour
l’entreprise et le client SOA de bien évaluer les risques liés au produit. Dans
la pratique, le responsable est généralement le faciliteur et l’organisateur de
l’analyse des risques du produit, sa tâche consistant à contacter les personnes susceptibles d’apporter une contribution par leurs connaissances. Le
Tableau 10.1 répertorie les candidats susceptibles d’être impliqués dans
l’analyse des risques.
201
SOA for Profit
Rôle
Élément central
Expertise
Client du service
métier, en principe
responsable du
processus métiers
Dommage (en cas de
problème, quel est le
dommage)
Processus métiers
Architecte
d’entreprise
Risque d’échec (quels sont les
domaines SOA ou services
sujets à l’erreur ?)
Expertise
Propriétaire du
Risque d’échec/dommage
service (technique ou
métier)
Service métier et technique
Analyste métier
Dommage
Processus métiers, service
métier
Utilisateur confirmé
Dommage
Processus métiers, service
métier
Développeur
Risque d’échec
Service métier et technique
Responsable projet
Dommage/risque d’échec
Tous les domaines
Assurance qualité
Risque d’échec
Tous les domaines
Administrateur
(fonctionnel et
système)
Dommage
Tous les domaines
Gestionnaire des
exigences
Dommage/risque d’échec
Service métier et technique
Tableau 10.1 : Candidats potentiels à l’analyse des risques d’un produit
Outre le fait que l’analyse des risques du produit constitue la base de la stratégie de test, on trouve un autre avantage : les différentes parties sont davantage sensibilisées aux risques et aux conséquences possibles. Une liste commune et largement soutenue des principaux risques avec leurs classifications
est ainsi constituée. Pour le reste du test, cette démarche facilite l’engagement au cas où des décisions devraient être prises dans le domaine
concerné.
Cependant, une simple séance de brainstorming avec quelques personnes sur
les risques du produit ne donnera sûrement pas de bons résultats quant à la
manière de couvrir les risques des éléments et du ou des services à tester. Le
but n’est pas d’envisager tous les risques produits possibles, mais d’évaluer
les risques liés à chaque élément ou aspect du service.
202
10 Comment arriver à bon port
Comme ce type d’analyse est principalement un outil de communication,
un bon moyen consiste à adopter le point de vue du client SOA et des
autres personnes impliquées (c’est-à-dire en adoptant la perspective de
ce qu’ils jugent essentiel). C’est l’étape de définition des « objectifs des
tests ». Il s’agit d’objectifs pertinents pour le client, souvent formulés en
termes de processus métiers basés sur l’informatique (commandes, facturation), d’exigences utilisateurs ou de cas d’utilisation à mettre en œuvre,
de facteurs de réussite critiques, de propositions de changement ou de
risques à traiter.
Pour chaque objectif, les participants doivent alors déterminer les caractéristiques qualité pertinentes. Autrement dit, quels aspects l’activité de test doitelle couvrir pour atteindre les objectifs ? En général, la caractéristique « fonctionnalité » ou « exactitude » est la bonne. Le responsable du test doit
expliquer que d’autres caractéristiques comme les performances, la convivialité et la sécurité peuvent aussi convenir, suivant leurs risques. Par exemple,
la performance est-elle un problème pour le processus métiers Commandes ?
Une fois toutes les caractéristiques de test sélectionnées pour chaque objectif, il faut les regrouper. Les participants divisent ensuite le service métier en
plusieurs ensembles d’objets (ou composants) pour chaque caractéristique.
Pour les Performances, vous pouvez avoir l’infrastructure, les services techniques spécifiques ou le service métier complet. Pour la Convivialité, il peut
s’agir d’écrans d’enregistrement ou de consultation des données et pour la
Fonctionnalité, de l’ESB ou des services techniques. Mais en principe, le service métier est divisé en plusieurs parties, par exemple les parties fonctionnelles pour les informations sur la gestion, les clients, les commandes et les
factures.
La division en composants permet d’aller plus loin dans le détail pour choisir
l’envergure du test. Les participants doivent attribuer une classe de risque
aux composants, allant d’un niveau bas à un niveau très élevé, en prenant en
compte le risque par rapport aux objectifs à atteindre. Voici un exemple dans
le Tableau 10.2.
203
SOA for Profit
Caractéristique/composant
Classe de risque
Fonctionnalité
• service 1
Élevé
• service 2
Intermédiaire
• service métier
Intermédiaire
Convivialité
Intermédiaire
Performance
• transactionnel
Intermédiaire
• batch
Bas
Tableau 10.2 : Évaluation des risques pour les caractéristiques
et les composants SOA de la qualité
Le résultat est intégré dans le plan de test (principal) ; il constitue la référence pour toutes les décisions ultérieures à prendre quant à la stratégie du
test (bas, intermédiaire, approfondi ou nul) pour chaque caractéristique
qualité/composant dans le cadre de la mise en œuvre de la SOA.
10.3.2 Définition de la stratégie de test
La stratégie de test comprend quatre étapes, comme l’indique la Figure 10.2.
Nous allons expliquer ces étapes plus en détail ci-après.
Le choix des niveaux de test
Une analyse des risques d’un produit est effectuée pour le processus de test
du service (métier) dans sa globalité. En principe, cette analyse porte sur une
multiplicité de niveaux de test. Les niveaux conventionnels sont le test d’unité,
le test d’intégration de l’unité, le test système et le test de validation (utilisateur et/ou production). Tout d’abord, il faut déterminer dans un plan principal, quels sont les niveaux à mettre en place. Les tests SOA nécessitent en
principe un autre niveau (supplémentaire) : le test du service. Ce niveau sert
à évaluer la qualité de chaque service (technique ou commercial de niveau
inférieur) qui sera utilisé dans le service métier. Cette méthode évite l’effet
Big Bang provoqué par l’intégration de tous les services dans le service
métier où l’on finit par se rendre compte que le service dans son ensemble
ne fonctionne pas correctement. Si la qualité d’un service est insuffisante, le
test d’un service particulier sera un outil d’évaluation bien meilleur que le
test du service métier dans sa globalité, une situation où il est beaucoup plus
difficile de remonter de l’origine d’un défaut à un service sous-jacent.
204
10 Comment arriver à bon port
Pour les tests de service, peu importe si les services sont achetés, réutilisés
ou récemment créés. Ce qui est compte, c’est le risque lié à un service spécifique. Pour un service acheté, ce risque diffère généralement d’un service
nouvellement constitué. Par exemple, dans un service sur étagère (non stocké)
auprès d’un fournisseur métier, vous pouvez vous attendre à trouver un nombre très limité de défauts fonctionnels par rapport à un service récemment
créé. En revanche, un service conçu et développé en interne sera sans aucun
doute mieux adapté à la SOA. L’analyse des risques doit mettre ces différences
en évidence.
Un aspect essentiel des tests, en particulier dans les environnements SOA,
est l’identification des responsabilités à chaque niveau. Le vendeur ou fournisseur d’un service est-il responsable du niveau de test ou celui-ci incombet-il à la partie demandeuse du service (informatique) ou de la solution
(métier) ? Parfois un doute subsiste, en particulier par rapport au test de
service. Nous préférons que l’utilisateur du service soit responsable de son
test. Cela ne signifie pas forcément que celui-ci doit aussi effectuer le test : le
test peut également être réalisé par le fournisseur du service si les résultats
sont revus par son utilisateur.
Choix entre tests simplifiés et tests approfondis
Pour déterminer l’envergure des tests, il faut utiliser comme point de départ
la classe des risques par composant (en se basant sur l’analyse des risques
produits). Initialement, le principe suivant prévaut : plus le risque est
important, plus le test requis doit être approfondi. Les résultats sont enregistrés dans un tableau de stratégie par niveau de test (cf. Tableau 10.3).
Caractéristique/ Classe de
composant
risque
Révision
Test des
développements
Test du
service
Test du
système
•
•
•
•
••
•
•••
••
•
••
Test de
validation
Fonctionnalité
•service 1
Élevé
•service 2
Intermédiaire
•service métier
Intermédiaire
Convivialité
Intermédiaire
•
••
Performance
•transactionnel Intermédiaire
•batch
•
Bas
••
•
Tableau 10.3 : Stratégie de test pour chaque caractéristique et composant
205
SOA for Profit
Dans le Tableau 10.3, le test des développements comprend des tests unitaires et des tests d’intégration unitaires. Le test du système concerne
l’intégration des services. Lors du test de validation, c’est le service métier
qui sera testé.
Les tests de non-régression, qui permettent de vérifier si les changements
apportés à l’environnement informatique (dans l’architecture, l’infra­
structure, les services ou les processus métiers par exemple) peuvent avoir
des conséquences imprévues à d’autres niveaux, sont importants. Comme
beaucoup de changements sont possibles (après tout, la SOA est destinée
à assouplir l’entreprise), ce test constitue l’armature d’une bonne stratégie
de test SOA et est souvent automatisé. Le test de non-régression est effectué à presque tous les niveaux.
Le plus souvent, un service ne possède aucune interface utilisateur. Pour le
tester, il faut créer une couche au-dessus du service, pour en faciliter l’accès
au moyen de certains paramètres d’entrée et en vérifier les performances.
Cette couche est appelée batterie de tests. Le développement (et le test !) de
cette batterie de tests est à prendre en compte lors de la planification du
test.
Tester un service (métier) nécessite des connaissances métiers. Les utilisateurs (finaux) possèdent ces connaissances, mais ils craignent souvent, à
cause de l’environnement technique, de tester individuellement chaque service. De même, il est difficile pour un utilisateur de tester un service de
manière isolée car les données sont souvent artificielles et non productives.
Impliquer les utilisateurs dans les tests de service nécessite une préparation,
une formation et un coaching.
Un service métier composé d’une multitude de services doit être testé à la fois
seul et en combinaison (intégration) avec les autres services/systèmes métiers.
Ces tests, communément appelés tests de validation utilisateur, représentent
un défi majeur à relever pour l’entreprise en termes d’environnements requis
(matériel, réseau, base de données, données). L’installation d’un environnement de test représentatif, stable et fidèle aux conditions de production,
nécessite une grande coordination entre entreprises, départements et équipes. Cela s’avère très complexe et souvent très onéreux. L’élément clé est
l’engagement précoce des individus possédant les connaissances dans l’infrastructure et l’environnement.
206
10 Comment arriver à bon port
Évaluation des efforts et établissement d’un planning
Une évaluation globale est alors entreprise en vue du test et un planning est
mis en place. Il est crucial d’effectuer des tests très tôt dans le cycle de vie du
développement d’un service en particulier dans le cas de la SOA. Les premiers tests peuvent mettre en évidence des problèmes de qualité assez faciles
à rectifier à ce stade alors que, plus tard, les coûts de modification augmente­
ront de manière considérable.
Les éléments sont communiqués aux clients et aux autres acteurs et en fonction de leur avis, modifiés si nécessaire. Le client exerce ainsi un certain
contrôle sur le processus de test, ce qui lui permet de travailler en trouvant
un juste milieu entre les résultats et les risques d’une part, et les délais et les
coûts d’autre part.
Il faudra répéter les étapes Choix entre tests simplifiés et tests approfondis et
Évaluation des efforts et établissement d’un planning jusqu’à ce que le client
soit satisfait de l’équilibre obtenu entre le temps et les coûts des tests évalués
d’une part, et les résultats à obtenir et les risques en jeu de l’autre.
Détermination des techniques de test
Lorsque le client et les acteurs clés définissent d’un commun accord la
stratégie, l’évaluation et le planning, le responsable du test transforme en
mesures concrètes toutes les décisions prises concernant les tests simplifiés
et approfondis à mener. Son rôle est de déterminer la manière dont le test doit
se dérouler, les techniques à employer pour couvrir un service de manière
ciblée, en associant les techniques d’élaboration des tests à des combinaisons
de caractéristiques des composants. La base de test disponible est notamment
prise en compte. Ces techniques sont utilisées pour mettre en place et réaliser
des études (et/ou check-lists) par la suite. C’est à ce stade que débute le
­processus de test principal.
Les activités que nous allons vous décrire sont effectuées dans le cadre du
processus de test global, les résultats étant enregistrés dans le plan principal.
Au niveau individuel (test d’unité, test de service, test de validation), les
actions sont plus détaillées, si besoin.
207
SOA for Profit
10.3.3 Test effectif
Après la validation du ou des plans avec la stratégie, les tests (préparation, spécification et exécution) démarrent. En cours d’exécution, le responsable donne
au client et aux autres acteurs, des informations et des options de contrôle sur :
•
L’avancement du processus
•
La qualité et les risques du ou des services testés
•
La qualité du processus.
10.4 Avantages de l’approche BDTM
L’approche BDTM évoquée plus haut, qui consiste à décider ce qui doit être
testé et à quel niveau de minutie l’opération sera effectuée, démontre
l’importance d’une bonne communication entre les testeurs et les acteurs clé.
Suivant le principe de la BDTM, la démarche choisie doit permettre au client
de contrôler le processus et d’aider à déterminer une stratégie. Le test prend
ici une allure professionnelle et devient rationnel. Les informations requises
à cette fin sont fournies par le processus de test.
L’approche BDTM présente les caractéristiques suivantes :
•
L’effort de test global est associé aux risques du système à tester pour l’entreprise. Le déploiement du personnel, des ressources et du budget s’effectue en
fonction des composants du système qui sont les plus importants pour elle.
•
L’évaluation et la planification du processus sont rattachées à la stratégie
de test définie. Si des modifications ayant un impact sur la complétude du
test pour les divers composants ou systèmes sont entreprises, celles-ci sont
instantanément répercutées dans l’évaluation et/ou le planning. L’entreprise a ainsi l’assurance de disposer à tout moment d’une vision juste du
budget, des délais et de la relation avec la stratégie de test.
•
Le client est impliqué dans les choix à différents moments du processus.
Avantage : le processus répond au mieux aux souhaits et aux exigences (et
donc aux attentes) de l’entreprise.
C’est encore loin ? Malheureusement oui. Le développement informatique
n’est jamais figé et la SOA, en particulier, est un environnement qui évolue
rapidement. Les risques changent, de nouveaux développements imprévus
font leur apparition, de nouvelles versions sont présentées, des services modifiés mis en place etc. Vous devez savoir qu’une analyse des risques d’un produit et une stratégie de test ne reflètent qu’une situation à un moment donné.
208
10 Comment arriver à bon port
Au cours du processus suivant, vous constaterez que certains risques ont été
exagérés, d’autres sous-estimés ou négligés. Le responsable du test devra
ainsi adapter la stratégie et les efforts associés ainsi que la planification. À la
base, il faut suivre les mêmes étapes que précédemment décrit pour réaliser
cet ajustement, mais seulement de manière beaucoup moins marquée. Cela
signifie à nouveau que le client garde une bonne maîtrise du processus et de
ses résultats : la qualité de SOA appropriée.
10.5 L’environnement de test SOA
Pour effectuer un test dynamique de la SOA, vous avez besoin d’un environnement adapté. La mise en place et le maintien de cet environnement se traduisent par l’introduction d’une expertise dont les testeurs n’ont en général
aucune notion. C’est la raison pour laquelle un département distinct – externe
au projet – est souvent chargé de cette mission. Néanmoins, les testeurs sont
très dépendants de cet environnement nécessaire au déroulement des tests.
L’environnement doit être constitué et installé en fonction de l’objet du test.
Sa réussite dépend du niveau de conformité de l’architecture SOA ou d’une
partie de l’architecture par rapport aux exigences prescrites. Chaque test peut
avoir un objectif différent ; c’est la raison pour laquelle chaque test peut
s’exécuter dans un environnement différent. Par exemple, le test d’un service
nécessite une configuration complètement différente de celle d’un test de
validation d’une architecture SOA complète.
Avec la SOA, une entreprise peut utiliser un nombre croissant de types de
matériel informatique et de logiciels. Lorsqu’on met en place un environnement de test pour ce type d’architecture, cela se traduit par une chaîne de
configurations matérielles et logicielles différentes avec des interfaces
mutuelles. L’idée selon laquelle « la chaîne est aussi résistante que son maillon
faible » se vérifie ici. En cas d’échec d’un service ou d’un maillon de la chaîne,
la chaîne complète est inutile et un test complet devient impossible.
L’organisation des environnements représente un défi que les testeurs doivent relever quelle que soit la situation. Comme la chaîne couvre une multiplicité de services, plusieurs départements sont impliqués. Par ailleurs, tous
les composants de l’environnement doivent être achevés en même temps, des
dispositions devant être prises pour les données de test requises dans les
différents composants.
209
SOA for Profit
Pour bien organiser cette démarche, les différents acteurs doivent préalablement se concerter sur la finalisation du plan de test principal. Nous vous
recommandons de créer la fonction de « coordinateur de chaîne » au sein du
processus de test. Ce coordinateur sera responsable de la mise en œuvre et
du maintien de l’environnement de test. Pendant la réalisation d’un test, il
devra s’assurer que tous les maillons de la chaîne sont en place, et servira
d’interface entre les différentes parties engagées dans le test.
Si plusieurs projets utilisent le même environnement, il faudra prendre des
mesures sur l’utilisation des données de test. Cela est le cas, lorsque par
exemple, le projet A est basé sur des tests utilisant les données du service A
et que le projet B modifie ce service. Il est possible, par exemple, que le projet
A récupère dans l’après-midi les données d’une version du service différente
de la version du matin, ce qui peut naturellement affecter la fiabilité des tests
du projet A. Pour empêcher cela, il est recommandé d’engager également la
responsabilité du coordinateur de chaîne sur ce type de situations. En liaison
avec toutes les autres parties engagées, ce coordinateur mettra en place un
plan de définition et de maintien des données de test.
10.6 Adaptation pendant les tests SOA
L’un des sept concepts simples de l’architecture SOA est basé sur le changement. Le principe « Faciliter le changement, progresser en permanence »
dénote à quel point le changement est omniprésent et comment la SOA peut
vous aider à réagir. L’idée selon laquelle les tests et les changements continus
ne font pas bon ménage, est très répandue. Beaucoup pensent que, si vous
devez procéder à des tests approfondis, vous avez besoin d’un produit stable
qui n’évolue pas. Sinon, il sera très difficile de tout tester. C’est faux.
En tant que testeur, vous devez posséder cette capacité à vous adapter aux
situations et aux besoins changeants. Cette aptitude ne consiste pas simplement à réagir face à un environnement qui évolue, mais aussi à favoriser les
changements pour le bénéfice des tests. Nous pouvons donc résumer les quatre caractéristiques d’adaptabilité dont doit faire preuve le testeur, à savoir :
•
Réagir aux changements.
•
(Ré-)utiliser les produits et les processus.
•
Capitaliser sur les retours d’expérience.
•
Essayer avant d’utiliser.
210
10 Comment arriver à bon port
Réagir aux changements
Au départ, l’adaptabilité consiste à déterminer ce que sont (ou peuvent être)
les modifications et à s’y adapter. Cette démarche doit s’opérer dès le début
de la mise en place du plan de test principal, lorsqu’on détermine et que l’on
inventorie les tâches à réaliser, que l’on obtient une vision de l’environnement
dans lequel chaque test est exécuté et que l’on définit les changements possibles. Pris ensemble, tous ces éléments jouent un rôle essentiel.
C’est précisément à ce stade que les fondements requis pour l’élaboration et
la mise en œuvre ultérieures du test se mettent en place. Quels niveaux, types,
phases et outils de test utiliser et comment ? Mais cela ne se limite pas à ces
activités. La stratégie et le plan associé sont définis en étroite collaboration
avec le client. Si celui-ci estime que la stratégie élaborée et l’évaluation ou le
plan associé ne sont pas acceptables, le plan sera modifié.
Par cette approche, le client a le contrôle du processus de test, ce qui lui permet de prendre des décisions en trouvant un juste milieu entre les risques et
les résultats d’une part, et les délais et coûts d’autre part.
(Ré-)utiliser les produits et les processus
Être capable d’utiliser rapidement les produits et les processus existants est
un pré-requis à l’adaptabilité. La SOA est constituée de services qui élaborent
les produits de test spécifiques à chacun. Peut-être qu’un de ces produits
pourra servir à tester un autre service (après quelques ajustements) ? Par
exemple, les résultats obtenus par un service pendant un test peuvent être
utilisés comme les paramètres d’entrée du test d’un autre service. Cela peut
également être le cas d’une batterie de tests développée pour un service spécifique. Après quelques modifications, le programme déjà au point pourra être
utilisé à un autre niveau dans l’architecture SOA. Le test de non-régression
est un dernier exemple. Il peut être établi sur la base des scripts et des batteries de test existantes. Il est donc essentiel d’avoir en permanence un œil
sur la nature des produits de test créés pour un service donné.
Outre la réutilisation des produits entre les services, nous préconisons aussi
la réutilisation des produits d’un test destinés à un service spécifique. À l’issue­
du test, ne jetez rien, mais conservez tout pour plus tard. Par exemple, pour
modifier un paramètre dans un service à cause d’exigences changeantes, il
peut être pratique de réutiliser les scripts de test précédents. Par ailleurs, il
faut mettre en place le test de manière à ce que les produits et les processus
puissent être préservés, puis utilisés et réutilisés encore et toujours.
211
SOA for Profit
Capitaliser sur les retours d’expérience
Vous devez apprendre et agir en fonction de votre expérience. Une évaluation
du processus de test s’impose alors. Les indicateurs quantitatifs sont un autre
outil essentiel. Pour les tests, mesurer la qualité des services ou l’avancement
et la qualité du processus lui-même est primordial. Les indicateurs sont utilisés
pour gérer le processus de test, justifier les recommandations et comparer les
systèmes aux processus. Ils permettent également d’améliorer les processus
par une évaluation de l’impact de certaines mesures d’amélioration des tests.
Essayer avant d’utiliser
Pendant les tests SOA, il faut pouvoir essayer avant d’utiliser. Ici, les principaux outils sont les activités liées à la validation. Une validation est une opération qui consiste à vérifier, à partir d’une check-list, si le sujet est conforme
aux exigences de qualité prédéfinies. Par exemple, en validant les paramètres
de base d’un test (les informations qui déterminent le comportement requis
d’un service), vous pourrez déterminer si le test est de qualité suffisante.
Avant de préparer le test et de créer des scripts, il faut vérifier la qualité des
informations. Très souvent, plusieurs fournisseurs de services sont impliqués,
d’où des différences possibles de qualité à tout moment. Cela peut aussi s’appliquer à un service.
Lorsque le test complet d’un service spécifique peut commencer, nous vous
recommandons de procéder à des vérifications préalables. Le but est de déterminer si l’objet testé est de qualité suffisante ou non pour continuer. Cette
opération consiste à exécuter des scripts spécialement conçus à cet effet.
Dans la pratique, la fourniture ou la mise en place d’un service laisse souvent
à désirer les premiers jours du test, ce qui retarde le début des opérations.
Ces décalages ne sont pas seulement des pertes de temps ; ils démotivent
également l’équipe chargée des tests.
10.7 Synthèse
Avant d’entamer le voyage SOA, toute entreprise doit déterminer les risques
qu’elle court et les mesures qu’elle envisage de prendre pour écarter ces
risques. Si vous ne voulez pas que les réponses à des questions aussi cruciales, ne vous parviennent qu’au stade de la phase opérationnelle de la SOA, il
faut prévoir à l’avance une méthode de test fiable. Dans la SOA, le processus
de test est différent du développement logiciel traditionnel, et l’on pourrait le
résumer comme suit :
212
10 Comment arriver à bon port
1.
2.
.
.
Qui est propriétaire, qui paie ?
Quand tester quel service ?
Comment tester un service ?
Qui dit beaucoup de services, dit beaucoup de tests.
Nous utiliserons l’approche BDTM pour mettre en place des tests qui couvrent les principaux risques liés à la mise en œuvre de la SOA. En effet, si
vous dépensez de l’argent pour la SOA, vous devez savoir ce que vous allez
obtenir en retour. Le concept de gouvernance informatique pilote les projets
SOA en fonction de quatre paramètres : résultats, risques, délais et coûts. Pendant les tests SOA, la justification économique de l’informatique joue un rôle
majeur et elle doit s’intégrer dans le processus de test. Cette approche BDTM
permet d’établir une certaine corrélation entre ces paramètres.
L’approche est basée sur un principe précis : la méthode de test choisie doit
permettre au client d’exercer un contrôle sur le processus de test et de déterminer (ou d’aider à déterminer) la méthode de test. Le test prend ici une
allure professionnelle et devient rationnel. Les informations requises à cette
fin sont obtenues à partir du processus de test.
Un environnement adapté est requis pour les tests dynamiques de la SOA. La
mise en place et la composition d’un environnement varieront en fonction de
l’objectif du test. Avec la SOA, une entreprise peut utiliser un nombre croissant de matériel informatique et logiciels différents. La composition de ces
environnements est un défi que les testeurs doivent relever, quelle que soit
la situation. Pour garantir une bonne organisation, les différents acteurs doivent se concerter à l’avance sur la finalisation du plan de test principal. Nous
recommandons la création d’un poste de « coordinateur de chaîne » au sein
de l’organisation de test.
La SOA peut aider les entreprises à évoluer, bien que l’idée selon laquelle les
tests et les changements continus ne font pas bon ménage soit très répandue.
En tant que testeur, vous devez être capable de vous adapter à des situations
et des besoins changeants. Par ailleurs, vous devez savoir favoriser les changements pour le bénéfice des tests. Les quatre qualités nécessaires aux testeurs sont donc les suivantes :
•
Réagir aux changements.
•
(Ré-)utiliser les produits et les processus.
•
Capitaliser sur les retours d’expérience.
•
Essayer avant d’utiliser.
213
es dix meilleures choses à dire pour se
11 Lfaire
renvoyer
L’architecture orientée services permet d’améliorer la façon dont le métier et
le service informatique travaillent conjointement. Ceci étant, nombres
d’écueils sont à éviter pour atteindre cet avenir prometteur. La majorité d’entre eux concerne l’adoption difficile d’une nouvelle façon de penser métier et
informatique.
Dans le présent chapitre, nous allons détailler dix idées reçues qui pourraient
sembler bonnes à un certain moment, mais qui sont en réalité « la meilleure
façon de vous faire renvoyer ». Nous présenterons une vision d’ensemble de
ces idées, ainsi que leur impact potentiel, et quelques alternatives pour y
remédier.
Dix choses à dire pour vous faire renvoyer :
1. N’en parlons pas au métier.
2. Faites-moi confiance : la SOA, ça coule de source.
. L’orientation processus est inutile.
. Construisons une tour de Babel.
. Demandons à notre nouvel architecte d’entreprise.
. Changeons les standards.
7. Lançons-nous avec la SOA à l’assaut de cibles mobiles.
. Que mille services éclosent.
. Orientons-nous services sans architecture.
10. Migrons tout vers la SOA.
11.1 « N’en parlons pas au métier »
La SOA concerne à la fois le métier et l’informatique. Pourtant, des membres
du personnel informatique pensent qu’il vaut mieux mettre en place une
approche SOA sans impliquer le métier. Pire encore : ils projettent de remettre en œuvre totalement leur informatique à l’aide des principes SOA sans en
avertir le métier.
215
SOA for Profit
Quel serait l’intérêt d’une telle démarche ? D’une part, l’expérience nous dit
qu’il est souvent difficile de parler au métier de problèmes informatiques. Au
fil des années, le service informatique a perdu de sa crédibilité auprès du
métier, et est désormais sous pression pour « simplement livrer ». La plupart
des discussions entre le métier et le service informatique tournent autour de
projets, de dates butoirs, et si oui ou non le service informatique peut être plus
efficace. De fait, il semble logique pour un directeur informatique d’utiliser la
SOA telle la voie royale pour améliorer l’efficacité de l’informatique sans
déranger le métier.
Deux choses au moins peuvent tourner mal avec cette façon de penser : la
stratégie et le financement.
Stratégie informatique
Si le service informatique souhaite vraiment être optimisé, encore faut-il qu’il
sache à quoi s’attendre. Il doit savoir quelles sont les nouvelles initiatives que
le métier va mettre en œuvre, quels seront les nouveaux produits à développer, ce qu’il va se passer avec les partenaires commerciaux, fournisseurs,
processus métiers, etc. Il n’y a aucun intérêt à optimiser un système qui sera
obsolète dans deux ans en raison du changement de l’état du marché. Le
service informatique aura quelques idées concernant les tendances générales,
mais cela n’a pas la même valeur qu’une stratégie informatique authentique
formulée et détenue par le service informatique et le métier. Le service informatique a besoin de repères clairs, définis par le métier, en fonction desquels
il est possible de mesurer ce qui va et ce qui ne va pas. Pour chaque décision,
il doit être capable d’évaluer la meilleure ou la pire option (d’une certaine
manière, le service informatique et le métier sont unis « pour le meilleur et
pour le pire »).
Le problème sous-jacent à cette idée finalement pas si brillante de ne pas
avertir le métier est qu’il n’y a pas assez de dialogue entre le métier et le service informatique. Il devrait être impossible au service informatique d’entreprendre une transformation architecturale sans impliquer le métier.
Financement
Une autre raison pour laquelle il devrait être impossible de mettre en œuvre
des changements si importants au sein du service informatique sans impliquer le métier est que c’est le métier qui, au final, les finance. Lorsque l’on
parle de réutilisation, d’outillage ou de nouvelle infrastructure (comme un
ESB), une nouvelle façon de calculer les frais doit être mise en œuvre. Le
216
11 Les dix meilleures choses à dire pour se faire renvoyer
métier veut savoir où va son argent, et surtout, ce qu’il recevra en échange.
Mais le financement basé sur des projets du service informatique auquel nous
nous sommes habitués, devra forcement changer. De tels changements ne se
limitent pas au niveau informatique, mais vont bien au-delà. Une business
unit dans une entreprise ne tient généralement pas à dépendre d’une autre
business unit pour ses projets. Toutefois, la SOA créera une infrastructure
partagée, des services partagés, voire des sous-processus partagés qui seront
utilisés par différentes sections, projets ou processus métiers. C’est là tout
l’intérêt de la mise en œuvre de la SOA. Mais si aucune politique n’est mise
en place pour appuyer cette banalisation, les silos organisationnels demeureront et forceront le service informatique à répliquer ces silos dans l’architecture. Dans de telles circonstances, la réutilisation reste une illusion.
Au début
Le directeur informatique obstiné rejettera peut-être l’idée d’avertir le métier
dès le début, arguant quelque chose du genre « Nous devons tout d’abord
établir notre propre compréhension de la SOA au sein du service informatique avant de pouvoir nous attaquer à la demande émanant du métier ». Aussi
logique que cela puisse paraître, il s’agit d’une hérésie. Naturellement, le
service informatique a beaucoup à apprendre lors de l’adoption de la SOA.
Le côté métier de l’entreprise a au moins autant à apprendre, et par conséquent, devra commencer son propre apprentissage dès que possible. Il en va
de même pour des déclarations telles que « Mais nous devons d’abord mettre
en œuvre un nouveau ceci ou un nouveau cela », ou « Nous devons d’abord
mettre de l’ordre dans certains problèmes anciens ». Il est indéniable que la
SOA nécessite beaucoup de « mises en ordre », mais cela ne se limite pas à
l’informatique. Le métier doit commencer à repenser ses processus métiers
et se préparer à l’avenir. Pour tirer le meilleur profit de la SOA, il faut se
développer conjointement et combler le fossé qui sépare le métier et le service informatique en commençant et en passant ensemble par la phase d’apprentissage.
S’adresser au métier
Par conséquent, est-ce que le métier doit tout savoir de la SOA ? Doit-il être
impliqué dans toutes ses étapes ? Bien sûr ! Mais au niveau métier. Un dialogue stratégique doit concerner une stratégie métier, fixer des priorités et
prendre des décisions d’un point de vue métier. Le métier ne doit pas être
gêné par des abréviations et des explications techniques. Au cours du dialogue, une vision réaliste loin des tendances de la SOA peut se développer pour
déterminer la valeur métier réelle de la SOA. Le métier peut définir claire-
217
SOA for Profit
ment ses attentes. Le service informatique peut retrouver son rôle en prenant
la responsabilité de la manière dont cela doit être accompli. (De fait, le métier
ne peut plus simplement déclarer « Nous achetons ce nouveau système informatique » ; il peut simplement préciser pour quels processus il demande un
support technique et laisser au service informatique le soin de décider de la
meilleure manière de le faire). Mais l’objectif principal est de créer un dialogue ouvert d’égal à égal. L’informatique peut inspirer le métier en repérant
de nouvelles opportunités qui peuvent se présenter grâce à de nouveaux
développements dans le monde informatique. Et le métier peut inspirer le
service informatique en partageant ce que d’autres entreprises accomplissent
avec leur service informatique.
Exceptions à la règle
C’est très rare, mais au cas où une entreprise disposerait d’un environnement informatique homogène (exclusivement en ordinateur principal ou exclusivement en SAP,
par exemple), la SOA est pratiquement inutile. Il n’existe habituellement aucun problème d’intégration, la perception du système est claire et la réactivité aux changements métiers sera rapide et fiable. Dans ce cas (uniquement), c’est une stratégie
parfaitement légitime de simplement suivre les remises à niveau des fournisseurs. Le
métier ne sera que peu affecté par les « remises à niveau » de la SOA dans ce genre
de situation. Néanmoins : un dialogue stratégique est nécessaire pour s’assurer que
la demande future puisse être satisfaite tout en suivant les fournisseurs.
11.2 « Faites-moi confiance : la SOA, ça coule de source »
Bien que les concepts de base de la SOA soient simples, il n’est pas facile de
les mettre en pratique. De nombreuses initiatives SOA échouent parce qu’elles étaient vendues en tant que solutions simples offrant rapidement des
résultats significatifs. Il convient de se rendre compte que la SOA en soit ne
résoudra pas les problèmes délicats de l’intégration, du patrimoine et de la
stratégie informatique de l’entreprise. La SOA fournira une structure avec des
meilleures pratiques utilisables pour déterminer et créer votre solution.
Péché ou ignorance ?
Ignorer la complexité de la SOA vous coûtera cher. Indépendamment de la
simplicité des concepts SOA, cette attitude aura de graves répercussions et
les questions délicates demeureront ce qu’elles étaient. Sous-estimer l’impact
ou la complexité provoquera l’échec des investissements dans des projets
informatiques, voire une perte financière pour le métier et le service infor-
218
11 Les dix meilleures choses à dire pour se faire renvoyer
matique. Si la SOA semble trop belle pour être vraie, il y a des chances que
tel soit effectivement le cas. Vendre la SOA en guise de solution rapide retardera les améliorations réelles de plusieurs années. Il existe quelques exemples de sociétés informatiques qui ont mis en œuvre des projets SOA finalement avortés en raison de l’impossibilité de montrer un résultat significatif
pour le métier. Du temps et des efforts ont été gâchés dans l’élaboration d’une
architecture parfaite que personne n’avait demandée.
Évolution, pas révolution
Un modèle de maturité comparable à celui présenté dans cet ouvrage, offre
une bonne vision d’ensemble de l’impact de la SOA et des démarches à entreprendre aujourd’hui et demain. Ce modèle devrait être utilisé en tant que guide
pour gérer les attentes : quels avantages métiers seront atteints, quand et dans
quel ordre. La mise en œuvre de la SOA peut correspondre à une évolution :
des étapes de petite envergure, chacune ayant une (certaine) valeur métier.
11.3 « L’orientation processus est inutile »
On peut considérer une entreprise de différentes façons. Généralement, il
existe un point de vue productiviste selon lequel des produits ou services
spécifiques offerts sont au centre du mode de pensée. À l’inverse, on trouve
le point de vue processus, selon lequel les produits en eux-mêmes ont peu
d’importance, contrairement aux processus que les partenaires ou clients
utilisent pour accomplir des tâches : pour demander une nouvelle politique,
pour changer une adresse ou pour poser une question.
Avec la SOA, nous prenons en considération les services fondamentaux proposés par l’entreprise. Ces services sont autant en rapport avec les produits
que les processus. Mais, surtout, les services concernent les capacités (fondamentales) d’une entreprise, ce qu’elle peut faire. Pour connaître ces capacités,
une vision du fonctionnement de l’entreprise est nécessaire. Cela revient ainsi
à concevoir un système informatique traditionnel : c’est seulement lorsque
les processus à supporter sont connus, que la conception d’un système en
adéquation avec l’activité quotidienne peut être faite.
Étant donné que l’architecture orientée services a bien plus de valeur lorsqu’elle est appliquée à l’entreprise dans son intégralité, une vision des processus parcourant l’entreprise entière est nécessaire : plus aucune limite au
sein de l’entreprise, ou même au-delà des limites entre l’entreprise et le
219
SOA for Profit
monde extérieur. Actuellement, la manière la plus pragmatique de considérer
une entreprise sans tenir compte des limites est d’adopter la vision orientée
processus : regarder de l’extérieur vers l’intérieur, pour trouver les processus
qui constituent l’entreprise.
Sans cette vision processus, votre SOA deviendra très probablement une
architecture en silos qui peut s’adapter aux produits actuels, mais ne fournira
pas l’agilité souhaitée.
En résumé, la SOA tente d’automatiser une entreprise selon la façon dont les
processus fonctionnent réellement et non selon leur structure, ce qui nécessite une approche orientée processus.
11.4 « Construisons une tour de Babel »
L’intégration est difficile car ce n’est pas un problème relevant exclusivement
de l’informatique. De multiples systèmes se connectent, la technologie est
utilisée pour transporter les données, voire pour transformer certaines données, de sorte que les systèmes de réception et d’envoi concordent. Bien
d’autres problèmes techniques devront éventuellement être résolus, tels que
la sécurité, la fiabilité, la performance, etc. Mais une condition très importante
doit être remplie afin que les systèmes se connectent : leur connexion doit
être logique a priori. En d’autres termes : la connexion doit être possible à un
niveau conceptuel. Un numéro représentant un produit dans un système doit
être transformable en un produit dans un autre système, et des données
comptables d’un bout du système doivent être intégrables aux données de
l’autre bout. Ou bien encore, à un niveau métier : « l’occupation » d’avions par
exemple doit avoir le même sens pour divers services : cela comprend-il le
personnel ? Cela comprend-il les passagers reportés sur un autre vol ? Cela
comprend-il des passagers qui ont payé mais n’ont pas pris l’avion ? Selon le
service auquel vous vous adressez, la réponse peut varier : le service comptable verra peut-être les choses différemment du service de la planification,
etc. Pour que leurs systèmes sous-jacents deviennent intégrables, un accord
doit définir comment interpréter les données. L’accord ne doit pas uniquement concerner les données, mais également les processus, la qualité attendue, la propriété, etc. La sagesse de l’histoire biblique concernant la tour de
Babel se vérifie une fois de plus : si tout le monde parle une langue différente,
la coopération pour atteindre des objectifs communs devient très compliquée,
voire impossible.
220
11 Les dix meilleures choses à dire pour se faire renvoyer
Quel péché ?
Si l’intégration ne relève que du service informatique, ce dernier prendra des
décisions qui ne peuvent qu’être prises à un niveau métier. Par conséquent,
ces systèmes ne donneront pas une image juste du fonctionnement de l’entreprise.
Cela peut se produire également à une échelle différente avec la définition
bottom-up de services : le service informatique cherchant à sauver des éléments de code réutilisables de systèmes existants en les renommant « services ». Cela peut marcher et des systèmes utilisables peuvent en découler par
le plus grand des hasards, mais il n’y a aucun gage de garantie que les services offriront une valeur métier.
De fait, comme nous l’avons déjà dit, pour tenir les initiatives bien intentionnées à l’écart du service informatique, l’entreprise doit prendre ses responsabilités en termes d’intégration et de SOA. L’entreprise doit prendre l’ascendant concernant l’intégration et s’impliquer activement dans la définition de
processus, dictionnaires, niveaux de services et bien d’autres problèmes d’intégration. Bien souvent, cela est établi dans des structures de gouvernance et
des mises en place de bons processus architecturaux. Une entreprise se comportant comme « propriétaire absent » est tout bonnement inadmissible.
11.5 « Demandons à notre nouvel architecte d’entreprise »
L’évolution de l’informatique d’entreprise offre de nouvelles opportunités de
carrière pour des esprits jeunes et brillants pour qui il s’agit du B.A.-BA. La
SOA n’en diffère en rien. Les novices en informatique qui adoptent la SOA
comme la façon logique par excellence de pratiquer l’informatique s’avèreront être des atouts lors de la mise en œuvre de la SOA.
Toutefois, un risque perdure : celui de réinventer la roue. Avec la SOA, nous
pouvons constater que ces éléments jeunes et brillants ont une connaissance technologique solide. Ils ont commencé par la programmation de services web, utilisant de nouveaux outils pour créer toutes sortes de solutions.
Désormais, ils sont passés à un stade où ils conseillent l’entreprise sur l’utilisation de la SOA. Mais leur expérience en matière de processus métiers,
gouvernance ou changements organisationnels est insuffisante.
221
SOA for Profit
Comme nous avons pu le constater, l’influence de la SOA sur les entreprises
est considérable. Cette influence est principalement organisationnelle plutôt que technologique : changer la façon dont les processus fonctionnent,
changer la façon dont la gouvernance est appliquée, etc. C’est alors que
l’expérience vient compléter l’intelligence et la connaissance des dernières
évolutions technologiques. Par la détermination réelle de la valeur, la vision
de ce qui est réaliste et ce qui ne l’est pas exige une expérience pratique.
Les nouveaux architectes d’entreprise ont tendance à se faire leur propre
expérience de la manière dont une architecture fonctionne, dont la gouvernance doit être appliquée, dont une stratégie informatique utile doit être choisie, etc. Naturellement nous pensons qu’une connaissance livresque ne peut
qu’aider, mais l’expérience de votre entreprise est bien plus importante. L’architecture orientée services est un outil très puissant, mais elle nécessite à la
fois une compréhension théorique et pratique de ce qu’elle est vraiment et
de la meilleure façon de l’appliquer. Si un de ces deux aspects manquent,
mieux vaut ne pas l’utiliser, de peur que cela ne se retourne contre vous. La
première étape avant d’utiliser la SOA consiste à apprendre ce dont il s’agit
véritablement et comment l’utiliser. Des initiatives selon lesquelles des entreprises commencent par échanger des expériences au sein d’un secteur d’industrie se sont avérées payantes au niveau d’une connaissance pratique pour
l’appliquer au mieux.
La façon idéale d’assurer que l’expérience s’ajoute à une connaissance nouvelle est de mettre en place un centre de compétence SOA (ou centre d’excellence SOA) dans lequel les principaux architectes SOA sont représentés.
Ce centre de compétence recevra logiquement le mandat explicite pour
consolider la connaissance tout en orientant les initiatives SOA.
11.6 « Changeons les standards »
Un des concepts simples de l’architecture orientée services comprend l’utilisation de standards. En ce sens, les « standards » sont les grands standards
internationaux, ainsi que les standards utilisés au sein de votre entreprise.
Une fois un accord passé sur la manière de résoudre un problème particulier,
cela devient un standard.
222
11 Les dix meilleures choses à dire pour se faire renvoyer
Si nous voulons réellement réduire les frais de maintenance, ces standards
doivent être utilisés comme prévu, sans changement ni décalage. Si un développeur, à un moment donné, a l’opportunité de prendre un raccourci en
« améliorant » légèrement un standard, vous perdez les avantages d’une
maintenance plus simple et de frais moins élevés. Si un nouveau système
reposant sur un standard « officiel » doit être mis en œuvre, mais ne peut
utiliser le standard légèrement « amélioré », nous sommes coincés à la case
départ : changements manuels pour s’assurer que tout fonctionne.
Pour que cela fonctionne, il faut de la discipline, de la gouvernance et du
contrôle. Mais surtout, tout le monde doit partager une vision commune : il
est important de s’en tenir aux standards comme convenu. Ceci est également valable pour l’entreprise. Une fois qu’un standard a été choisi, il ne
peut pas être mis de côté, tout ça parce qu’un nouvel outil doit être mis en
place rapidement. Des objectifs à long terme tels que la souplesse, la cohérence et la réutilisation ne devraient pas être sacrifiés au profit d’objectifs
ou de priorités à court terme. Les standards ne sont valables que si chacun
y adhère.
11.7 « Lançons-nous avec la SOA à l’assaut des cibles mobiles »
L’agilité est l’objectif souhaité. Il peut paraître logique de supposer que, avec
la SOA, tout le service informatique sera en perpétuel changement pour s’aligner sur le métier. De même que la dérive en matière d’objectifs rendra tout
projet ingérable, rendre « tout agile » empêchera d’atteindre l’ensemble des
promesses de la SOA. L’agilité doit entrer en jeu précisément aux « points
névralgiques » du changement. Le secret d’une SOA réussie consiste à distinguer ce qui doit changer et ce qui ne doit pas changer.
Pour y parvenir d’un point de vue informatique, il faudra considérer les composants techniques qui vont durer dans le temps et qui seront configurables
pour répondre aux demandes métiers changeantes. D’un point de vue métier,
ce but sera atteint en identifiant les processus et les exigences dont la durabilité est supérieure aux autres. Cette recherche des aspects changeants et
constants au niveau informatique et métier correspond véritablement à « l’architecture émergeante » : trouver et définir les structures qui dureront plus
longtemps que des changements au jour le jour.
223
SOA for Profit
L’architecture métier consiste essentiellement à trouver les capacités et processus fondamentaux : que fait véritablement votre entreprise et que fera-telle demain ? Quelles sont les vérités « éternelles » auxquelles nous pouvons
nous fier ? Et c’est là que nous en revenons au message le plus important :
seul un dialogue stratégique entre informatique et métier permet d’atteindre
ce but. Ainsi, le métier ou plutôt les architectes métiers apprendront à réfléchir à des innovations et à des développements métiers pour les faire coïncider avec les exigences de l’informatique actuelle.
11.8 « Que mille services éclosent »
Laisser chaque projet résoudre ses propres problèmes, développer et déployer
autant de services qu’il le souhaite peut sembler une bonne idée. Il peut
paraître judicieux de décider de gérer les services en doublons par la suite.
Ou qu’il convient de résoudre des problèmes lorsqu’ils se présentent, dans le
cas de services qui ne sont pas parfaitement alignés avec un objectif
métiers.
Il nous faut ici tirer profit de nos expériences passées. Avec l’émergence d’Internet, de nouvelles solutions ont abondé, faciles à établir, à déployer, émergeant de toutes parts. Et nous payons toujours les frais de maintenance de
tous ces systèmes semi-redondants, dont chacun possède sa propre base de
données, son propre serveur ou son propre outillage. Il existe un risque
sérieux que cela se reproduise avec les services : d’ici un certain nombre
d’années, il pourrait y avoir au sein de votre entreprise plus de services qu’il
ne peut raisonnablement y en avoir de maintenus par aucune équipe informatique. La raison tient au fait qu’il est bien trop simple de créer de nouveaux
services.
Voici un exemple parlant de la manière dont des services peuvent apparaître
rapidement : une compagnie d’assurance a autorisé le demurrage de quelques
projets avec peu ou aucune directive ou supervision. Après quelques mois
seulement, entre six et dix services avaient été mis en œuvre pour fournir les
mêmes données client : chacun avec un léger décalage.
Les leçons du passé : ne jamais remettre à « plus tard »
Si vous voulez que les choses soient bien faites, commencez à bien faire dès
le début. Il est très difficile de corriger les erreurs du passé une fois qu’elles
224
11 Les dix meilleures choses à dire pour se faire renvoyer
sont là. Au lieu de penser : « nous pourrons améliorer notre portefeuille de
services plus tard », préférez : « nous devons gérer notre portefeuille de services dès le début ».
Que faire ?
Certaines mesures permettent de garantir la bonne gestion de votre portefeuille de services. Tout d’abord : générer un processus d’architecture pour
aborder et mettre en œuvre l’architecture au cœur des projets. Ce n’est qu’une
fois que la vision de l’architecture d’entreprise est partagée qu’elle peut se
développer vraiment. De manière plus pragmatique, assurez-vous que
l’outillage approprié est utilisé pour la gestion de services dès la mise en
route. Un registre et un référentiel permettent de lister les services existants
et à venir, y compris les niveaux de services, la propriété, les versions, etc.
Seuls les plus forts survivront
Avec la SOA, l’ensemble des services proposés par l’informatique doit coller
à la demande de l’entreprise. Une entreprise en perpétuel changement implique également que le portefeuille de services soit continuellement sous surveillance : des services vont disparaître, d’autres seront modifiés, de nouveaux
seront disponibles, d’autres encore reconfigurés. Au final, seuls survivront les
services les mieux adaptés aux demandes du métier.
11.9 « Orientons-nous services sans architecture »
Les preuves ne manquent pas pour montrer que les services ou « l’orientation
services » sans une architecture solide ne fonctionnent pas. De même, la plupart des articles tirés de la presse et d’Internet concernent l’outillage, la technologie ou les fournisseurs de logiciels SOA. L’architecture orientée services
n’est pas un outil ou un produit livré en kit : c’est une véritable architecture.
Structure, contrôle et cohérence sont indispensables. Les services doivent
s’aligner sur le métier. Les projets doivent prendre en compte les aspects
inter-projet. Le service informatique doit trouver et définir ce les éléments
stables et instables au niveau informatique. L’architecture est indispensable
au fonctionnement de la SOA. Sans architecture, le risque généré des services
est supérieur aux opportunités qu’ils créent.
225
SOA for Profit
Afin que l’architecture fonctionne, le credo du just enough, just in time devra
être solidement ancré dans les processus quotidiens du service informatique.
L’architecture requiert des processus autant qu’elle requiert des modèles et
des abstractions. Et l’architecture ne suit pas un modèle bottom-up : il s’agit
d’une décision top-down pour mettre en œuvre et promouvoir l’architecture
au sein de l’informatique et du métier.
11.10 « Migrons tout vers la SOA »
Lorsque l’on aborde la SOA, elle s’impose comme un bon modèle à suivre
pour structurer l’informatique. De fait, la migration ou la remise à niveau de
l’informatique existante vers une architecture orientée services peut sembler
attrayante. Soyons honnêtes : qui ne voudrait pas se débarrasser de toutes ses
antiquités informatiques ? Nous ne souhaitons pas pourtant affronter un big
bang : trop risqué. En vérité, nous n’aimons rien de démesuré ; c’est souvent
trop cher pour en tirer un intérêt métier. Où se situe donc la SOA ?
La SOA peut être mise en œuvre petit à petit : en appliquant de plus en plus
de principes à un nombre grandissant de domaines informatiques. Comme
l’illustre le modèle de maturité, différents aspects peuvent être améliorés à
différents moments. Il semble que le « chaos » ne soit pas la condition sine
qua non à la mise en œuvre de la SOA.
Il est bon d’avoir cette vision d’un monde idéal où tout n’est que SOA. Cela
peut vous guider pour montrer ce qui peut être atteint au sein de votre entreprise. Néanmoins, les principes architecturaux doivent être appliqués selon la
règle du just enough, just in time. Une informatique réellement orientée métiers
nécessite également des investissements qui soient au plus près des risques
et objectifs métiers. Aucune cas métier ne peut justifier le remplacement de
tous les systèmes informatiques par des systèmes orientés services, au même
titre qu’il n’y a aucun intérêt à moderniser deux systèmes qui ne font que
communiquer entre eux. Aucune cas métier ne peut justifier la remise à niveau
du système de courrier électronique existant avec un système « orienté services ».
Cela vaut pour tous les modèles : seuls vos objectifs spécifiques déterminent
dans quelle mesure le modèle doit être mis en œuvre. Il vous appartient de
définir votre niveau d’objectif SOA spécifique. Il dépend de votre métier de
226
11 Les dix meilleures choses à dire pour se faire renvoyer
savoir dans quelle mesure vous avez besoin de la SOA, où ce besoin s’exprime
et ce que vous pouvez en attendre.
Péché ou simple effervescence ?
Vouloir migrer tout vers la SOA constitue-t-il un péché si grave en soi ? Ce
désir devrait être considéré comme un péché cardinal parce qu’il va à l’encontre de l’objectif premier de la SOA : simplifier l’informatique. La SOA est
populaire pour sa capacité à faire de l’informatique un support gérable, rentable et efficace pour le métier, support qui aurait toujours dû exister. Nous
ne faisons que tester à grande échelle ce qui pose un risque métier, nous ne
faisons qu’optimiser ce qui offre une optimisation métier, nous ne faisons
que changer ce qui améliore le mode de gestion du métier. Affirmer que
l’informatique dans son intégralité doit être changée au profit de la SOA
implique que la SOA devienne une fin en soi, ce qui est une erreur monumentale.
Une note en passant
Alors qu’en règle générale il n’existe pas de cas métier pour des migrations de grande
envergure vers la SOA de type « tout ou rien », il peut y avoir quelques rares exceptions à cette règle (pas dans votre entreprise) : dans certains cas, des fournisseurs
externes peuvent proposer des services qui correspondent si parfaitement au processus interne qu’un changement suffisant s’opère pour donner de l’élan nécessaire. Il
devient finalement possible de se débarrasser des systèmes patrimoniaux construits
par le passé et de tout recommencer. En particulier dans des secteurs où la banalisation se produit très rapidement, les fournisseurs de services seront impatients de
combler les écarts qui apparaissent dans ce nouveau marché banalisé. Et dans certains cas, le désordre interne est assez conséquent pour justifier un pas en avant
radical : tout recommencer à zéro.
Combien, quand, comment ?
Dans le modèle de maturité décrit dans le présent ouvrage, vous trouverez un
outil précieux pour déterminer les démarches à suivre et l’ordre en fonction
duquel vous pourrez gravir les échelons de la SOA. En outre, vous devrez
développer une vision SOA et déterminer en quoi elle peut vous aider dans
votre cas spécifique : faire correspondre les objectifs métiers, les problèmes
et l’opérationnel et mettre en regard les avantages de la SOA. Dès lors, vous
pourrez établir votre propre feuille de route SOA.
227
12 Le voyage continue
Quel bilan, quelles perspectives ? Dans le présent ouvrage, nous avons montré comment vous pouvez tirer parti d’une architecture orientée services.
Nous avons décrit les avantages que vous pouvez escompter, à savoir une plus
grande agilité informatique et des frais de maintenance réduits. Nous avons
traité la façon dont la SOA peut résoudre les problèmes de longue date au
niveau informatique et métier, tels que la solution aux problèmes d’intégration et la réutilisation du patrimoine existant.
Comme nous avons pu le constater, les concepts sur lesquels s’appuie la SOA
sont simples et basés sur l’expérience informatique accumulée au cours des
30 dernières années. Cette architecture se compose de concepts simples :
segmenter en composants, toujours avoir une raison métiers d’agir et réutiliser des composants chaque fois que l’opportunité se présente. Commencer à
utiliser cette architecture amorce une transformation qui nécessite une planification et une gouvernance minutieuses. De plus, grâce à l’agilité croissante
de l’informatique sous l’influence de la SOA, la gouvernance et l’architecture
constituent des facteurs clé pour que le métier et l’informatique restent alignés et empêchent que les initiatives SOA ne deviennent incontrôlables.
Un environnement informatique basé sur la SOA permet une nouvelle
approche du métier et les principes d’orientation services peuvent s’appliquer aux processus métiers eux-mêmes. Pour déterminer les services
métiers qui constituent votre métier et le considérer avec le niveau d’abstraction adapté, vous devez comprendre votre métier (chose facile) et trouver une façon de le modéliser. Nous avons montré comment l’étudier de près
sous plusieurs angles d’attaque afin de pouvoir définir un ensemble de services et de capacités viables qui définissent l’essence même de votre
métier.
L’introduction de la SOA a des conséquences directes sur vos collaborateurs et
sur le rôle qu’ils jouent au sein de votre entreprise. La fonction d’architecte
d’entreprise se renforce car celui-ci veillera personnellement à combler le fossé
qui sépare habituellement le métier et l’informatique. Il aidera à guider l’entreprise tout au long du passage à la SOA. Outre l’aspect humain, nous avons
également abordé la manière dont la SOA affectera l’entreprise elle-même.
229
SOA for Profit
Nous avons présenté un modèle intitulé bus de services humain (Human Services Bus) qui peut être utilisé pour développer au maximum l’agilité au moyen
de la SOA. Nous avons également défini les éléments organisationnels qui
devront être mis en place pour permettre la gouvernance requise.
En pratique, vous pouvez commencer par une définition de votre stratégie et
de votre vision métier, puis utiliser le modèle de maturité pour établir un itinéraire spécifique à l’entreprise vous conduisant vers la SOA. Le modèle de maturité énumérera les aspects de entreprise qui doivent être améliorés afin d’atteindre le niveau d’adoption de la SOA nécessaire pour appliquer votre
stratégie métier. Étant donné que l’établissement de votre SOA se fait en grande
partie dans des projets métiers « ordinaires », la définition de points d’entrée
potentiels, qui cernent des projets SOA éligibles, exige toute votre attention.
Nous explorons aussi de quelle manière un processus de test de maturité permet d’éviter les risques lors de la mise en œuvre de la SOA.
Tel est le bilan ; nous sommes au seuil de l’informatique de demain. Une
nouvelle façon de concevoir l’informatique est née, et nous pouvons en tirer
profit. On ne peut guère dire qu’elle est simple, mais elle n’en demeure pas
moins gérable et graduelle. Elle semble le bon chemin à suivre. Mais qu’est-ce
qui nous attend au bout du chemin ?
12.1 Destinations futures
Lorsque l’architecture orientée services deviendra le modèle d’architecture
prépondérant et que les entreprises se seront libérées de leur patrimoine et
de leur informatique inflexible, de nouvelles opportunités se présenteront et
commenceront à révolutionner le métier. De même qu’Internet a changé graduellement mais radicalement les rapports avec les clients, la SOA changera
le rapport métier avec les partenaires, les fournisseurs et les clients. Elle
changera la façon dont nous utilisons l’informatique et dont nous faisons des
affaires. Nous allons vous donner un aperçu de l’avenir possible que nous
réserve la SOA. Avenir lointain, dont nous ne serons peut-être même pas
témoins.
La souplesse change le métier
La lente évolution de l’informatique ne constituant plus un obstacle pour
elles, les entreprises changeront rapidement et pourront mieux s’adapter aux
230
12 Le voyage continue
circonstances. De nouveaux modèles métiers feront leur apparition, à l’instar
du modèle HSB, dans lesquels les unités organisationnelles seront faiblement
couplées, et pourront proposer leurs services sans tenir compte des limites
organisationnelles. Votre secrétaire pourra commencer à travailler pour
d’autres entreprises, simplement parce qu’il y a un business case qui le justifie. Des intermédiaires, qui jusqu’ici revendaient simplement vos services,
composeront un ensemble personnalisé de services parfaitement adapté à la
demande de vos clients.
Se recentrer sur son cœur de métier
La distinction entre informatique « infrastructurelle » et informatique « innovante » deviendra plus évidente, donnant aux entreprises la liberté de se
concentrer sur leurs activités fondamentales et d’investir dans leur cœur de
métier. Il ne sera plus nécessaire de consacrer plus de la moitié du budget au
fonctionnement de l’entreprise. L’argent sera en grande partie investi dans la
création de valeur et l’innovation. Cela sera d’autant plus précieux dans un
monde où les métiers doivent assurer une augmentation permanente d’efficacité et de rendement pour s’attaquer à des problèmes vastes et coûteux, tels
que la mondialisation, le vieillissement et la menace du changement climatique.
Le nouveau monde d’Internet
En fournissant des services qui utilisent la SOA, les entreprises seront parfaitement équipées pour entrer sur le nouveau marché : le marché Internet
mondial où le monde est flat et les prestataires de services aux quatre coins
du monde sont en concurrence pour élargir leur base clients. Internet passera
d’un réseau d’informations à un réseau de services. De même que vous pouvez aujourd’hui consulter un bulletin météo, vous pourrez demain trouver
toutes les fonctions métiers dont vous avez besoin : qui seront mes RH et à
quel prix ? Qui me fabriquera ce produit et dans quel délai ?
Innovation et intuition
Grâce aux nouveaux modèles métiers, modifier un aspect d’un processus
métiers ou ajouter de nouvelles capacités ne perturbent pas l’entreprise dans
son intégralité. Il devient plus simple d’innover. Si l’innovation est assez simple, on pourra même innover grâce à la technique des essais et des erreurs :
définir une large gamme de nouveaux produits ou services et vérifier lequel
connaît un succès immédiat ou rechercher comment modifier certains d’entre
eux pour trouver les meilleurs marchés.
231
SOA for Profit
Non seulement Internet permet une présence étendue sur le marché international, en fournissant de la demande et un modèle de fourniture pour des
services et produits de niche, mais l’innovation développe également notre
flair. Ce dernier permet d’élargir notre champ d’innovation afin de détecter
les futurs grands marchés ou marchés de niche. À son tour, l’innovation en
matière d’essai et d’erreur s’adaptera parfaitement aux tendances Internet
2.0, où des actions et réseaux sociaux de nombreux particuliers contribuent
directement à façonner l’innovation. Un creuset d’innovations et une capacité
à faire évoluer rapidement votre gamme de produits ou de services vous donneront les clés du marché. Des offres orientées services, permettant la combinaison et la personnalisation, rendront possible cette évolution.
Nouvelles générations
De nouvelles générations de digital natives entreront en scène, prenant les
solutions qui s’y trouvent et les faisant passer au niveau supérieur. Ces digital
natives feront en sorte que la technologie corresponde à leurs attentes en
matière de fonctionnement de l’informatique : omniprésente, toujours en
marche, invisible et entièrement fiable. L’aspect du respect de la vie privée
posant moins de problème, ils s’attendront à ce que les solutions informatiques suivent facilement leur attentes dans tout ce qu’ils font, en s’adaptant
aux processus individuels et aux préférences personnelles. Leurs mouvements sur Internet et dans les mondes virtuels et sociaux font partie intégrante de leur identité. L’informatique leur permet de s’exprimer et d’être
productifs. Le travail et le loisir se recouperont, l’informatique n’étant jamais
considérée comme restrictive mais plutôt comme permissive. L’architecture
orientée services fournira les services qu’ils utiliseront pour constituer leur
monde informatique.
L’étape suivante dans l’évolution de nouveaux médias incorporera davantage
la technologie dans la vie de tous les jours et la fera passer à l’arrière-plan en
la fusionnant avec toutes sortes d’anciens médias tels que la télévision, le
téléphone et même l’écrit. L’interface avec le monde numérique se fondera à
l’interface avec le monde tel que nous le connaissons.
Finalité de l’informatique
Une grande partie de l’informatique deviendra la simple infrastructure qu’elle
devrait être : des services courants prenant en charge des tâches courantes.
Stockage de données client, gestion de règlements, expédition de marchandises ne seront plus spécifiques à une unité ou à une entreprise. Ils constitueront une infrastructure, prête à être utilisée en cas de besoin, optimisée
232
12 Le voyage continue
pour un coût réduit et un meilleur rendement. À commencer par des modèles
de haut niveau et des définitions de données partagés, les éléments courants
deviendront de plus en plus rapidement disponibles. Les grands fournisseurs
de logiciels profiteront de modèles métiers ouverts permettant le mélange des
technologies. L’informatique basée sur la description deviendra réalisable,
bâtissant des solutions informatiques sans programmation ni configuration,
qui utiliseront uniquement des méta-descriptions de l’entreprise telles que
les descriptions de processus, une feuille de route de capacité et une feuille
de route de services.
Une petite partie, quoique essentielle, de l’informatique permettra toujours
des innovations métiers. De nouvelles avancées en matière d’informatique
donneront aux entreprises un avantage sur la concurrence, ne serait-ce qu’à
court terme. Elles tenteront de suivre les technologies de pointe et de trouver
en elles la valeur métier par le biais d’essais et d’erreurs.
12.2 À condition de…
Le voyage menant à ce monde SOA potentiel de demain ne sera pas de tout
repos. Équilibrer en permanence les gains à court terme et les améliorations
à long terme demande toujours une grande attention en matière de gestion.
La réelle complexité des évolutions simultanées dans tous les domaines peut
nous dépasser. Un processus d’innovation clair est essentiel afin de générer
une stratégie pour traiter ces développements. Développer une organisation
informatique mature tout en gérant, par exemple, les défis que rencontrent
les ressources humaines au quotidien, ne constituera pas un projet à court
terme. Développer une vision partagée à long terme et la mettre à jour, améliorera peu à peu tous les aspects interconnectés du métier et de l’informatique.
Dans le présent ouvrage, nous avons abordé les conditions les plus importantes pour guider votre entreprise vers une SOA réussie. Votre entreprise peut
espérer obtenir des avantages considérables avec la SOA, mais seulement à
condition de :
•
Avoir une gouvernance structurée pour que l’entreprise s’adapte à des
circonstances changeantes et que l’informatique s’adapte à l’évolution du
métier.
•
Utiliser une architecture solide pour rendre la gouvernance manœuvrable et la relier aux développements informatiques.
233
SOA for Profit
•
Développer une vision d’ensemble SOA pour vous assurer que la SOA
ne soit pas considérée comme un développement technologique ou présentée comme une « solution rapide » pour des problèmes importants dans
le service informatique actuel.
12.3 Passez à l’action
Quoi que l’avenir nous réserve, nous y parviendrons plus tôt que vous ne
l’imaginez. Les changements interviennent sans cesse plus vite, intensifiant
l’urgence de se débarrasser de structures informatiques restrictives.
Si vous voulez que votre entreprise soit prête pour ce nouveau monde, commencez votre voyage vers la SOA dès maintenant. Evaluez votre maturité
actuelle ; établissez une vision métier et une stratégie SOA pour vous assurer
que votre entreprise sera également capable de jouer un rôle important dans
un monde SOA.
Mettez-vous au travail, commencez petit mais n’essayez pas de prendre des
raccourcis : assurez un plus grand équilibre en vous attaquant à tous les aspects
nécessaires à une coopération mature entre le métier et l’informatique.
234
13 Annexe : Modèle de maturité SOA
13.1 Présentation
Le modèle de maturité SOA a été présenté au Chapitre 8. Cet outil permet à
toute entreprise désireuse de se préparer à la SOA de porter l’attention nécessaire, dans la bonne direction et au bon moment. Le modèle de maturité SOA
vous aide à reconnaître les étapes indispensables à l’amélioration de secteurs
tels que le Processus, la Technologie et les Ressources humaines, tous prioritaires à un moment donné.
En premier lieu, pour identifier les étapes d’amélioration requises, il est
nécessaire d’évaluer si l’on est prêt pour la SOA dans les 20 secteurs clé du
modèle de maturité. La présente Annexe vous aide à faire cette évaluation.
Elle identifie des point de contrôle pour chaque niveau de secteur clé afin de
déterminer si l’entreprise a atteint le niveau en question.
Pour mieux appréhender la structure de la présente Annexe, il est utile de se
reporter au modèle de maturité SOA.
Dans le modèle de maturité, les colonnes représentent les différents stades
de croissance de la maturité. Les lignes représentent les 20 secteurs clé. Les
lettres indiquent le niveau de maturité à chaque stade. L’amélioration progressive se lit de gauche à droite.
Il faut observer les règles suivantes lors de l’application du modèle de maturité :
•
Une entreprise atteint un niveau lorsque tous les points de contrôle de ce
niveau ainsi que des niveaux précédents ont été atteints.
•
Une entreprise atteint un stade de maturité lorsque tous les niveaux de ce
stade ainsi que des stades précédents ont été atteints.
Les sections individuelles consacrées à chacun des secteurs clé dans le modèle
de maturité SOA sont présentées dans l’ordre d’apparition des secteurs dans
le modèle, en commençant par Engagement et Motivation. Les niveaux (A, B,
235
SOA for Profit
C et D) dans chacun des secteurs seront soumis à discussion. Des points de
contrôle sont fournis à chaque niveau. Ces derniers peuvent être utilisés pour
repérer la position de votre entreprise et la manière de l’améliorer.
Stade
Secteur clé
0 1 2 3 4 5 6 7 8 9 10 11 12 13
1
Engagement et motivation
A
2
Relations avec les projets
3
Rôles et responsabilités
A
4
Développement de l’architecture
A
5
Utilisation de l’architecture
6
Outils architecturaux
(méthodologie et logiciels)
7
Gestion de la qualité
8
Gestion du portefeuille de
services
9
Vision de l’architecture
A
Budgétisation et planification
12
Technologie et standards
13
Subdivision et réutilisation
C
B
B
C
B
C
B
B
B
C
C
B
B
B
C
B
C
D
A
B
C
A
B
C
19 Connaissance et état d’esprit
SOA du personnel
informatique
A
B
C
20 Connaissance et état d’esprit
SOA du personnel métiers
A
B
C
Figure 13.1 : Modèle de maturité SOA
236
D
C
A
A
D
D
B
A
18 Compétences SOA du
personnel métiers
C
B
A
D
D
B
A
A
C
C
A
Compétences SOA du
personnel informatique
C
B
A
A
D
C
A
15 Souplesse du système
d’information (infrastructure
et applications)
17
B
A
14 Mise en œuvre de processus
métiers dans le système
d’information
16 Sécurité de l’information
C
A
10 Alignement métier du système
d’information
11
B
D
C
D
C
D
D
13 Annexe : Modèle de maturité SOA
Dans le modèle de maturité, les colonnes représentent les différents stades
de maturité. Les lignes représentent les 20 secteurs clé. Les lettres indiquent
le niveau de maturité à chaque stade. L’amélioration progressive se lit de
gauche à droite.
Il faut observer les règles suivantes lors de l’application du modèle de
­maturité :
•
Une entreprise atteint un niveau lorsqu’elle satisfait à tous les points de
contrôle de ce niveau ainsi que des niveaux précédents.
•
Une entreprise atteint un niveau de maturité lorsque tous les stades de ce
niveau ainsi que des précédents ont été atteints.
Les paragraphes consacrés à chacun des secteurs clé dans le modèle de maturité SOA sont présentées dans l’ordre d’apparition des secteurs dans le
modèle, en commençant par Engagement et Motivation. Les niveaux (A, B, C
et D) dans chacun des secteurs seront commentés. Des points de contrôle sont
fournis pour chaque niveau. Ces derniers peuvent être utilisés pour repérer
la position de votre entreprise et la manière de l’améliorer.
13.2 Engagement et motivation
A : Budget et temps disponibles pour les initiatives SOA
Un budget et du temps sont mis à disposition pour un nombre limité d’initiatives SOA. Ces initiatives doivent prouver que la SOA peut apporter de
la valeur ajoutée à l’entreprise. À ce stade, la SOA n’a pas encore été acceptée comme une future orientation architecturale privilégiée pour l’entreprise.
Points de contrôle
•
Un budget est-il prévu pour les initiatives SOA ?
•
Du temps est-il prévu pour les initiatives SOA ?
•
La SOA est-elle considérée par la direction métier et informatique comme
un développement important ?
B : L’approche SOA est soutenue par la direction de l’entreprise.
LA SOA est désormais communément acceptée en tant que type d’architecture privilégié pour le métier et le service informatique et la direction générale de l’entreprise promeut ce choix.
237
SOA for Profit
Points de contrôle
•
La SOA est-elle activement promue par la direction métier et service informatique ?
•
Lors de la mise en œuvre d’une nouvelle fonctionnalité, la SOA constituet-elle le choix standard de type d’architecture privilégié ?
C : L’approche SOA est intégrée dans les processus de l’entreprise
Le choix de la SOA est désormais entièrement intégré dans les processus de
l’entreprise. L’idée que la SOA a une valeur stratégique pour l’entreprise
bénéficie d’un large soutien et il convient d’y accorder toute l’attention nécessaire.
Points de contrôle
•
D’ancienne fonctions ont-elles été remplacées de façon proactive par de
nouvelles fonctionnalités basées sur la SOA ?
•
La SOA représente-t-elle un élément crucial pour les collaborateurs de
l’entreprise ?
•
Un chapitre consacré à la SOA a-t-il été ajouté aux plans de projet comme
un élément standard ?
•
La direction oriente-t-elle délibérément des projets de sorte qu’ils soient
conformes à l’architecture d’entreprise basée sur la SOA ?
•
La SOA fait-elle partie du plan stratégique de l’entreprise ?
13.3 Relations avec les projets
A : Architecture pour la communication sur les projets
Les architectes orientent les projets vers une architecture SOA, mais il y a
encore peu d’interaction entre l’architecte et le projet ; aucun retour d’informations ne parvient à l’architecte si bien que ce qui est appris pendant le
projet ne peut pas être intégré dans l’architecture cadre.
Points de contrôle
•
Les projets prennent-ils en compte l’architecture d’entreprise basée sur
la SOA ?
•
Les projets sont-ils informés dès le départ que l’architecture d’entreprise
est basée sur la SOA ?
238
13 Annexe : Modèle de maturité SOA
B : Le processus d’architecture prend en compte les retours
d’informations du projet.
Le processus d’architecture entre l’architecture et les projets a été suffisamment régularisé pour que les architectes puissent disposer d’un retour d’informations et adapter l’architecture SOA, le cas échéant.
Points de contrôle
•
L’architecture d’entreprise basée sur la SOA est-elle adaptée pour prendre
en compte à l’expérience accumulée au cours de différents projets ?
•
Le respect de l’architecture d’entreprise basée sur la SOA fait-il partie du
processus de développement standard ?
C : Les architectes, l’entreprise et le service informatique établissent
conjointement l’architecture du projet
La création de l’architecture de départ du projet est un processus conjoint
dans lequel les architectes et les principales parties prenantes sont impliqués.
Points de contrôle
•
Les architectes aident-ils les développeurs à appliquer l’architecture d’entreprise basée sur la SOA à leur situation spécifique ?
•
Les développeurs peuvent-ils proposer des modifications à l’architecture
d’entreprise basée sur la SOA ?
•
L’architecture du projet basé sur la SOA est-elle le résultat d’une coopération entre les architectes et les développeurs ?
D : Dialogue permanent entre les architectes, le métier et le service
informatique
Un dialogue permanent entre les architectes et les principales parties prenantes leur permet d’aligner l’architecture de référence, l’architecture initiale
du projet et leurs expériences en la matière, et adapter en conséquence les
livrables et les projets, le cas échéant.
Points de contrôle
•
Existe-t-il un processus standard selon lequel les architectes et les projets
peuvent être en interaction ?
•
Existe-t-il un processus standard précisant la façon dont les modifications
apportées aux livrables du projet peuvent être intégrées aux livrables de
l’architecture de référence ?
239
SOA for Profit
•
La consultation standard entre les architectes et les développeurs portant
sur la manière dont leur coopération mutuelle peut-elle être améliorée ?
13.4 Rôles et responsabilités
A : Le service informatique est responsable de l’architecture et du
processus
Le service informatique est responsable de l’architecture basée sur la SOA et
du processus de mise en œuvre de la SOA. À ce stade, aucun rôle ni définition
clairs n’ont été établis pour le métier.
Points de contrôle
•
Le choix de la SOA pour l’entreprise en tant que style d’architecture privilégié est-il clair ?
•
La responsabilité d’une architecture d’entreprise basée sur la SOA a-t-elle
été intégrée dans l’entreprise ?
•
La responsabilité de l’identification, de la spécification, de l’établissement
et le retrait progressif des services (durée de vie des services) a-t-elle été
intégrée dans l’entreprise ?
•
Les rôles et responsabilités de la mise en œuvre de la SOA ont-ils été
intégrés dans l’entreprise ?
B : Le service informatique et le métier collaborent sur le processus
d’architecture
Le système informatique et le métier collaborent désormais sur un processus
architectural, et les rôles et responsabilités de la mise en œuvre de la SOA ont
été définis des deux côtés.
Points de contrôle
•
Le métier assume-t-il la possession d’un service ?
•
Le métier participe-t-il à la gestion du portefeuille de services ?
•
Les rôles et responsabilités de la mise en œuvre de la SOA sont-ils partagés par le service informatique et le métier ?
C : La responsabilité de la détention du processus est transversale.
La responsabilité sur les processus métiers a été intégrée de bout en bout et
s’étend sans problème au travers des différents domaines métiers et organisationnels.
240
13 Annexe : Modèle de maturité SOA
Points de contrôle
•
La responsabilité de bout en bout de processus métiers a-t-elle été intégrée dans le métier ?
•
La responsabilité de réutilisation de services a-t-elle été intégrée dans le
métier ?
•
Au cours de la mise en œuvre de la SOA, les objectifs des processus métiers
ont-ils plus de poids que ceux des entités ou des directions ?
13.5 Développement de l’architecture
A : Architecture mise en œuvre dans les projets
La formulation de livrables d’architecture SOA se fait en rapport avec un
projet concret, comme d’une architecture de début de projet.
Points de contrôle
•
Toutes les parties prenantes ont-elles été informées que l’entreprise a
choisi la SOA comme style d’architecture privilégié ?
•
Une description d’architecture SOA a-t-elle été formulée pour chaque
projet ?
•
Si l’utilisation de d’architecture projet ou d’architecture de début de projet
est déjà standard, une attention particulière est-elle portée à la SOA ?
B : Architecture en tant que processus transversal
Mettre en place une architecture SOA se fait désormais dans tous les projets
et toutes les directions, en tant qu’architecture de référence, par exemple.
Points de contrôle
•
Existe-t-il des principes et modèles généraux de SOA au sein de l’entreprise qui s’appliquent à tous les projets ?
•
Y a-t-il une architecture d’entreprise au sein de l’entreprise qui porte une
attention particulière à la SOA ?
•
Existe-t-il une quelconque gestion des mises en production pour l’architecture d’entreprise ?
C : Architecture en tant que processus de facilitation
Produire une architecture SOA fait partie d’un processus d’architecture dans
lequel les gens savent que le seul but de l’architecture est de soutenir les
changements nécessaires pour atteindre les objectifs métier. Avec chaque
241
SOA for Profit
forme d’architecture mise en place, le but et la fonction de l’architecture sont
clairs dès le départ.
Points de contrôle
•
Les principes et modèles SOA constituent-ils un composant inextricable
de l’architecture d’entreprise de la société ?
•
Les parties prenantes ont-elles toutes accepté le choix de l’entreprise de
privilégier la SOA en tant que style d’architecture ?
•
Lors de la mise en place de l’architecture d’entreprise, a-t-on convenu de
qui devra se conformer aux décisions prises ?
13.6 Utilisation de l’architecture
A : Architecture utilisée à titre informatif
L’architecture basée sur la SOA offre une vision claire de l’orientation que
compte prendre l’entreprise grâce à la SOA et pousse les gens à suivre cet
objectif. De plus, cette vision est mise en valeur par la direction. Tous les
membres des équipes ont accès à l’architecture.
Points de contrôle
•
Une architecture d’entreprise a-t-elle été approuvée par la direction ?
•
L’architecture d’entreprise donne-t-elle une vision claire de ce que veut
l’entreprise ?
•
Le choix de la SOA en tant que style architectural privilégié est-il clair ?
•
L’architecture d’entreprise est-elle facilement accessible à tous les membres des équipes ?
B : Architecture utilisée pour orienter le contenu
L’architecture SOA est véritablement utilisée pour orienter les options relevant de la SOA dans les projets. Les projets doivent être conformes à l’architecture.
242
13 Annexe : Modèle de maturité SOA
Points de contrôle
•
L’architecture d’entreprise est-elle utilisée pour guider les développements informatiques et métier au préalable ?
•
Pour chaque projet, sait-on précisément quelle partie de l’architecture
d’entreprise se rapporte un projet ?
•
Sait-on dans quelle mesure un projet doit être conforme à l’architecture
d’entreprise le concerne ?
C : Architecture intégrée à l’entreprise
L’architecture basée sur la SOA fait partie intégrante du pilotage de l’entreprise. C’est un facteur déterminant dans les processus de décision.
Points de contrôle
•
L’architecture d’entreprise est-elle utilisée dans les processus de décision
de l’entreprise ?
•
L’architecture d’entreprise est-elle utilisée dans les cycles de contrôle et
de planification de l’entreprise ?
•
La vision de la SOA s’appuie-t-elle sur la vision de l’entreprise qu’en a la
direction générale ?
13.7 Outils architecturaux (méthodologie et logiciels)
A : Initiatives non coordonnées
Des méthodes et outils sont utilisés pour les initiatives SOA, mais vérifier si
ces méthodes et outils sont compatibles ne constitue pas une priorité.
Points de contrôle
•
Des méthodes et outils sont-ils utilisés pour identifier et modéliser les
services ?
•
Des méthodes et outils sont-ils utilisés pour gérer le portefeuille de services ?
•
Des méthodes et outils sont-ils utilisés pour contrôler l’utilisation des
services ?
243
SOA for Profit
B : Rationalisation de l’outillage et politique d’intégration. Un
processus d’architecture global est défini.
Les méthodes et outils sont soigneusement choisis conformément au processus d’architecture défini. La politique est formulée afin d’assurer une
meilleure intégration mutuelle des méthodes et outils.
Points de contrôle
•
Les méthodes et outils soutiennent-ils le processus d’architecture ?
•
Les méthodes et outils soutiennent-ils le processus de développement ?
•
Les méthodes et outils soutiennent-ils le processus de contrôle ?
•
La gestion des méthodes et outils a-t-elle été integrée de façon explicite ?
•
Les architectes utilisent-ils les mêmes outils ?
C : L’outillage est exhaustif et intégré. Un processus d’architecture
global est formalisé
On est arrivé à une situation où les méthodes et outils sont entièrement et
mutuellement intégrés et sont parfaitement adaptés au processus d’architecture.
Points de contrôle
•
La durée de vie complète d’un service peut-elle être gérée à l’aide
d’outils ?
•
Le portefeuille complet de services peut-il être géré à l’aide d’outils ?
•
Les outils utilisés sont-ils intégrés de quelque façon que ce soit ?
•
Les architectes, développeurs et le soutien opérationnel utilisent-ils un
seul environnement d’outil ?
13.8 Gestion de qualité
A : Validation informelle ultérieure
L’architecture basée sur la SOA et les livrables du projet final sont validés a
posteriori, et on tente de répondre à la question suivante : les choix et les
produits livrables du projet correspondent-ils à la stratégie et aux objectifs
métier de l’entreprise ? Aucune norme n’a été préalablement définie.
244
13 Annexe : Modèle de maturité SOA
Points de contrôle
•
A-t-on tenté de valider l’architecture d’entreprise basée sur la SOA de
quelque manière que ce soit ?
•
A-t-on tenté de valider les services conçus de quelque manière que ce soit ?
B : Une évaluation a posteriori selon des indicateurs standardisés
Les normes auxquelles l’architecture basée sur la SOA et les livrables du
projet doivent se conformer ont été préalablement définies. La validation doit
avoir lieu a posteriori selon lesdites normes.
Points de contrôle
•
Les normes de qualité ont-elles été spécifiées pour les services ?
•
Les normes de qualité ont-elles été spécifiées pour l’architecture d’entreprise ?
C : Le processus de qualité d’architecture SI est défini. Gestion de
qualité permanente.
Un processus a été conçu afin de garantir la qualité de l’architecture basée
sur la SOA et des livrables du projet.
Points de contrôle
•
Un processus a-t-il été mis en place pour garantir la qualité des services ?
•
Un intérêt structurel est-il porté à la qualité du processus d’architecture ?
•
Existe-t-il un programme de qualité pour la SOA ?
D : Le processus de qualité d’architecture SI est intégré au processus
de qualité de l’entreprise
La garantie de qualité de l’architecture et des livrables du projet fait partie
intégrante de la politique de qualité de l’entreprise.
Points de contrôle
•
La qualité de l’architecture d’entreprise fait-elle partie de la politique de
qualité globale de l’entreprise ?
•
Un intérêt structurel est-il porté aux conséquences de la mise en œuvre
de la SOA dans l’entreprise ?
•
La relation avec les processus dans l’entreprise (processus de conception
de stratégie, processus architecturaux, processus de développement, processus de gestion) est-elle prise en compte dans des considérations concernant la qualité de la SOA ?
245
SOA for Profit
13.9 Gestion de portefeuille de services
A : Les durées de vie des services correspondent à celles des
applications qui les livrent
Les services métiers sont liés à une application et adaptés le cas échéant de
la même manière que l’application elle-même.
Points de contrôle
•
La gestion d’un service est-elle liée à une application offrant ledit service ?
•
Si nécessaire, un service est-il adapté lorsque l’application offrant ledit
service est adaptée ?
B : Accords sur les niveaux de services
La gestion des services métier ne se fait plus d’emblée selon les applications
mais selon les contrats de service (accords sur les niveaux de services) en
vertu desquels le client et le fournisseur du service conviennent des conditions de livraison du service.
Points de contrôle
•
Existe-t-il un contrat de service pour chaque service ?
•
Avant la conception du service, un contrat de service comprenant le cahier
des charges et les conditions selon lesquelles le service est fourni est-il
formulé au préalable ?
C : Durée de vie prévue (y compris le retrait)
Les services métier sont désormais gérés comme portefeuille à part entière,
ce qui signifie que les décisions concernant la durée de vie intégrale des services sont prises en fonction du portefeuille complet de services.
Points de contrôle
•
Les services de l’entreprise sont-ils gérés comme un portefeuille ?
•
Existe-t-il un mécanisme qui détermine le prix d’un service en fonction
de son utilisation ?
•
Existe-t-il des accords clairs concernant un service réutilisé ?
•
Existe-t-il des accords clairs concernant ce qui se passe lorsqu’un service
est retiré progressivement ?
246
13 Annexe : Modèle de maturité SOA
D : Financement de l’utilisation de services (marché de services)
Un marché de services a été établi. Les clients et fournisseurs de services y
négocient les services. La conception et le refus de services découlent de cette
négociation.
Points de contrôle
•
Est-il possible pour un fournisseur de service de retirer progressivement
ledit service en cas d’échec de négociation avec le client ?
•
Le prix d’un service est-il déterminé en fonction de son niveau d’utilisation ?
•
Les utilisateurs et fournisseurs de services peuvent-ils négocier les conditions de livraison et les tarifs ?
13.10 Vision de l’architecture
A : Vision de l’architecture “en l’état”
L’état actuel de l’architecture est connu et spécifié. Les défauts de l’architecture sont également identifiés.
Points de contrôle
•
L’architecture d’entreprise actuelle (en l’état) est-elle décrite en termes de
processus, services, applications, données, infrastructure technique et relations entre ces derniers ?
•
Les goulots d’étranglement de l’architecture d’entreprise actuelle sont-ils
évidents ?
B : Vision des évolutions à court terme
Outre l’architecture actuelle, un aperçu des développements SOA à court
terme et de leur niveau d’influence sur l’architecture actuelle s’impose. Partant, un nombre limité d’architectures de référence de domaine est mis en
place pour orienter les développements à court terme.
Points de contrôle
•
Connaît-on clairement les composants de l’architecture d’entreprise
actuelle influencés par le choix de la SOA ?
•
L’architecture d’entreprise comprend-elle des principes d’identification,
de conception et d’établissement de services ?
•
Des architectures de référence (proches ou lointaines) sont-elles disponibles aux domaines où la SOA est en cours de mise en œuvre ?
247
SOA for Profit
C : Vision de l’architecture à long terme
Conformément à la stratégie de l’entreprise, une architecture d’entreprise est
mise en place pour identifier les principales caractéristiques des changements dans le domaine de l’architecture technologique, de l’information et du
métier. L’entreprise a désormais à sa disposition un plan à long terme reflétant sa vision sur le métier et l’informatique.
Points de contrôle
•
Une architecture de référence à l’échelle de l’entreprise englobant la description de la vision SOA par l’entreprise est-elle disponible ?
•
La société possède-t-elle une architecture d’entreprise acceptée par la
direction générale ?
D : Alignement permanent de la vision sur les objectifs métiers à court
et long terme
L’entreprise dispose d’un processus grâce auquel des considérations architecturales permettent un alignement permanent des objectifs métiers et stratégiques sur les processus actuels, le schéma organisationnel, la fourniture
d’informations et l’infrastructure technique d’une entreprise.
Points de contrôle
•
L’entreprise a-t-elle à sa disposition un processus grâce auquel la stratégie
s’aligne en permanence sur le fonctionnement actuel ?
•
L’entreprise a-t-elle à sa disposition une architecture d’entreprise précisant clairement les conséquences de la stratégie de l’entreprise sur les
opérations actuelles et l’informatique ?
13.11 Alignement des systèmes d’information sur le métier
A : Les applications et les services sont conçus pour atteindre les
objectifs métiers (menés par le métier)
Les services et les applications sont conçus en se reportant aux besoins de
l’entreprise et en établissant un lien explicite avec les objectifs métiers.
Points de contrôle
•
Les services et les applications sont-ils uniquement conçus lorsqu’un business case clair les concernant se présente ?
248
13 Annexe : Modèle de maturité SOA
•
•
Lors de la conception de services et d’applications, la notion selon laquelle
ils doivent aider à atteindre les objectifs métiers constitue-t-elle le point
de départ ?
Les exigences du métier sont-elles connues avant que les services et les
applications ne soient en cours de conception ?
B : Tests sur la compatibilité des applications et services avec les
objectifs métiers.
Les services et applications sont désormais testés a posteriori pour évaluer
leur compatibilité avec les besoins et objectifs métiers.
Points de contrôle
•
Y a-t-il une validation a posteriori (au moyen de tests, entre autre) pour
voir si les services et applications conçus satisfont les exigences spécifiées ?
•
L’entreprise a-t-elle à sa disposition un processus de test de services formalisé ?
C : Le processus d’architecture soutient l’entreprise
Les services et applications sont conçus dans un processus d’architecture
dirigé par les objectifs métiers de l’entreprise. Les services et applications
conçus sont entièrement déterminés en fonction des changements métier
envisagés.
Points de contrôle
•
L’entreprise dispose-t-elle d’un processus d’architecture décrivant les étapes selon lesquelles les services et applications sont conçus ?
•
L’entreprise dispose-t-elle d’un processus d’architecture qui commence
par les objectifs stratégiques et métier de l’entreprise ?
D :Le processus d’architecture facilite les évolutions métier
L’aspect architectural fait partie intégrante de l’entreprise. Les architectes et
les représentants métier participent conjointement au dialogue stratégique
en fonction duquel une orientation est donnée au processus déterminant les
services et applications à concevoir.
Points de contrôle
•
Les évolutions métiers se produisent-elles uniquement lorsque l’architecture a été établie à cette fin ?
249
SOA for Profit
•
•
•
Le métier se sent-il impliqué dans le processus d’architecture ?
Le métier est-il un partenaire de discussion régulier dans l’établissement
de l’architecture ?
Les architectes sont-ils impliqués dans les processus de conception de la
stratégie ?
13.12 Budgétisation et planification
A : Nécessité de justifier formellement un RCI direct pour chaque
projet métier sur lequel la SOA a un impact
Chaque projet ayant un impact SOA est testé selon son rendement (tel que le
RCI, rendement du capital investi).
Points de contrôle
•
Chaque projet SOA est-il testé selon certains objectifs de rendement ?
•
Un budget est-il établi pour chaque projet SOA ?
B : Spécifique au projet SOA
Chaque projet SOA est précédé de la formulation d’un calendrier prévisionnel
et de l’établissement d’un budget.
Points de contrôle
•
Un calendrier prévisionnel est-il formulé pour chaque projet SOA ?
•
L’évolution d’un projet SOA est-elle surveillée ?
C : Générique entreprise
Il existe une méthode de planification et de budgétisation standard pour les
projets SOA au sein de l’entreprise.
Points de contrôle
•
Existe-t-il une méthode de planification et de budgétisation standard pour
les projets SOA ?
•
Dans la mise en œuvre des projets SOA, y a-t-il des écarts avec le budget
formulé et le calendrier prévu et documenté ?
D : Optimisation permanente du processus de planification et de
budgétisation
La budgétisation et la planification des projets SOA peuvent être professionnalisées à l’aide d’une révision structurelle de la qualité de planification.
250
13 Annexe : Modèle de maturité SOA
Points de contrôle
•
Existe-t-il un processus structuré pour bénéficier de retours d’informations sur les méthodes de planification et de budgétisation utilisées dans
les projets SOA ?
•
Des statistiques sont-elles disponibles concernant les anciennes budgétisations et les anciens calendriers prévisionnels des projets SOA ?
13.13 Technologie et standards
A : Technologie ad hoc choisie en cas de besoin
Une technologie et des standards SOA sont choisis lorsqu’un problème
concret se pose.
Points de contrôle
•
Les choix de base ont-ils été faits concernant certaines technologies et
certains standards SOA ?
•
Des standards SOA sont-ils disponibles au sein de l’entreprise ?
B : Référentiel de base informatique défini et éprouvé
Dans le domaine de l’informatique, les standards et technologies SOA
ont été soigneusement sélectionnés selon des concepts avérés.
Points de contrôle
•
Les choix concernant les technologies et standards SOA sont-ils uniquement faits lorsque la technologie ou le standard a été testé au sein de
l’entreprise en question (au moyen d’un concept avéré, par exemple) ?
•
La gestion de standards SOA a-t-elle été intégrée à l’entreprise ?
C : Stratégie motivée
Le choix de standards et technologies découle d’une stratégie à l’échelle de
la SOA.
Points de contrôle
•
Les choix de technologies et standards SOA sont-ils déterminés en fonction d’une stratégie à l’échelle de la SOA et d’une architecture d’entreprise
de la société ?
•
Les choix concernant les technologies et standards SOA sont-ils faits en
rapport avec d’autres technologies et standards ?
251
SOA for Profit
D : Anticipation de changements technologiques et adoption de
nouveaux standards
De nouveaux standards et de nouvelles technologies sont suivis et mis en
œuvre en permanence dans le cadre d’une stratégie à l’échelle de la SOA, dès
que cela s’avère utile.
Points de contrôle
•
Les développements de marché dans le domaine de la technologie et des
standards SOA sont-ils suivis de manière proactive ?
•
Un processus standard permet-il d’évaluer de nouvelles technologies et
de nouveaux standards SOA ?
13.14 Subdivision et réutilisation
A : Réutilisation non coordonnée
La réutilisation et la subdivision ont lieu, mais plus ou moins par hasard.
Points de contrôle
•
Existe-t-il une sorte d’enregistrement central des services indiquant le
degré de réutilisation ?
•
Y a-t-il des critères (tels que des standards et des principes) qu’un service
doit respecter ?
B : La réutilisation est coordonnée au sein du service informatique
(services techniques)
Des mécanismes ont été mis en œuvre avec le service informatique pour
pousser à la réutilisation et à la subdivision.
Points de contrôle
•
Un mécanisme a-t-il été mis en œuvre pour assurer que, en cas de besoin
d’une nouvelle fonctionnalité, une enquête soit faite pour vérifier si les services ou composants déjà disponibles peuvent offrir cette fonctionnalité ?
•
Dans le domaine informatique, existe-t-il une culture de la réutilisation
avant de développer de nouveaux éléments ?
C : La réutilisation est coordonnée au niveau métiers (services métiers)
Des mécanismes ont été mis en œuvre pour que la réutilisation et la subdivision se fassent également au niveau métiers.
252
13 Annexe : Modèle de maturité SOA
Points de contrôle
•
Dans l’entreprise, existe-t-il une culture d’utilisation de l’existant, avant
de faire appel à un nouveau processus ou service ?
•
Dans l’entreprise, un mécanisme a-t-il été mis en œuvre pour assurer que,
au niveau métier, les processus (étapes) et services existants sont réutilisés
autant que possible ?
D : L’informatique et le métier sont subdivisés et la réutilisation est
monnaie courante
La réutilisation et la subdivision constituent un principe généralement accepté
dans la restructuration de l’informatique et du métier. Ce principe est incorporé dans la méthode de fonctionnement standard de l’entreprise, en ce qui
concerne le changement.
Points de contrôle
•
Au sein de l’entreprise, la culture consistant à d’abord réutiliser ce qui est
disponible est-elle généralisée ?
•
L’entreprise a-t-elle à sa disposition une méthode de fonctionnement pour
le développement informatique et métier dans laquelle la réutilisation
occupe une position prédominante ?
13.15 Mise en œuvre de processus métiers dans le système d’information
A : Services métiers existants au sein de silos
Des services métiers ont été mis en œuvre de sorte qu’ils sont liés aux systèmes d’information de type silo actuels. Les liens avec les processus métiers
n’ont pas été pris en compte.
Points de contrôle
•
Les services métiers sont-ils en cours de conception pour rendre les systèmes existants plus ouverts ?
•
Les services métiers ont-il été mis en œuvre au moyen d’un lien avec des
systèmes existants ?
B : Processus transversaux
Les services métiers ont été mis en œuvre, prenant en compte les liens avec
les processus métiers ; la vision va au-delà des systèmes et structures
actuels.
253
SOA for Profit
Points de contrôle
•
Les services métiers sont-ils en cours de conception pour soutenir spécifiquement les processus métiers ?
•
Les services métiers sont-ils décrits en des termes compréhensibles et
reconnaissables ?
•
Les processus métiers sont-ils divisés en domaines clairement distincts ?
C : Supervision de l’activité métier (Business Activity Monitoring – BAM)
Le but du BAM est de surveiller les processus métiers automatiquement.
Points de contrôle
•
Le BAM est-il utilisé afin de surveiller la performance des processus
métiers ?
•
Peut-on surveiller de façon adaptée la performance des processus métiers
et les services métiers liés à ces derniers ?
D : Le métier et l’informatique collaborent pour établir et déployer des
processus métiers.
Le métier et l’informatique travaillent en étroite collaboration pour améliorer
les processus métiers et, grâce aux services métiers pouvant être reliés de
façon souple, les mettre en œuvre dans l’entreprise.
Points de contrôle
•
Grâce à l’utilisation de services métiers existants, l’entreprise est-elle
capable de mettre en œuvre de nouveaux processus métiers de manière
indépendante ?
•
L’entreprise a-t-elle à sa disposition un processus standard selon lequel
les services métiers sont identifiés, conçus, établis et progressivement retirés par les services métiers et le service informatique en parfaite collaboration ?
13.16 Souplesse du système d’information (infrastructure et applications)
A : Systèmes d’information basés sur des silos comprenant des
applications basées sur les services et du matériel informatique pour
les faire fonctionner.
Les systèmes d’information restent des silos, mais on utilise des services techniques dans ce genre de système.
254
13 Annexe : Modèle de maturité SOA
Points de contrôle
•
L’entreprise a-t-elle commencé à élargir ses applications patrimoniales
grâce aux services techniques ?
•
Les services techniques ont-ils été mis en œuvre au sein de l’entreprise ?
B : Certaines applications et infrastructures sont partagées au sein de
silos (flous) en raison de la rationalisation.
Certaines applications et éléments d’infrastructure sont mis à disposition en
tant que services aux systèmes d’information ayant des caractéristiques
apparentées aux silos. Une certaine réutilisation (technique) peut avoir
lieu.
Points de contrôle
•
Les services techniques utilisés plus d’une fois ont-ils été mis en œuvre
au sein de l’entreprise ?
C : Système d’information orienté processus, reconfigurable et
urbanisé.
Les systèmes d’information consistent désormais majoritairement en des services métiers alignés sur les processus métiers qu’ils doivent soutenir.
Points de contrôle
•
Les services métiers utilisés plus d’une fois ont-ils été mis en œuvre dans
l’entreprise ?
•
Les fonctionnalités sont-elles largement mises à disposition des processus
métiers via les services métiers ?
D : Virtualisation des systèmes information-métier dissociés.
Les systèmes d’information sont entièrement dissociés des processus métiers
qu’ils soutiennent. Les processus métiers utilisent des services métiers et ne
savent pas où et comment ces derniers sont mis en œuvre.
Points de contrôle
•
Les processus métiers dans l’entreprise sont-ils entièrement dissociés des
systèmes qui les supportent ?
•
Les processus métiers peuvent-ils être modifiés sans avoir à régler les
systèmes sous-jacents ?
255
SOA for Profit
13.17 Sécurité
A : Réactive
L’entreprise est consciente jusqu’à un certain point du besoin de protéger les
informations. Le service informatique a installé un ensemble minimal de
mesures de sécurité. La sensibilisation aux risques pris par l’entreprise en
matière de protection de messages et de services est faible.
Points de contrôle
•
Au sein de l’entreprise, y a-t-il une sensibilisation aux risques encourus
dans le domaine de la sécurité des informations ?
•
L’entreprise a-t-elle pris des mesures pour protéger les messages et les
services ?
•
La sécurité des informations est-elle importante dans l’application de la
SOA ?
B : Individuelle
L’organisation est plus au fait du thème de la sécurité des informations et des
risques encourus, mais seul le service informatique prend des mesures, telles
que la protection de la communication par le biais d’un ESB. L’entreprise dans
son intégralité ne s’intéresse pas encore vraiment à l’analyse des risques et
à la formulation d’une politique de protection des informations.
Points de contrôle
•
Au sein de l’entreprise, les gens sont-ils largement sensibilisés aux risques
encourus dans le domaine de la sécurité des informations ?
•
Le service informatique a-t-il pris des mesures suffisantes (telles que
l’authentification et le cryptage) pour protéger les messages et les services ?
C : Collective
Des standards et principes à l’échelle de l’entreprise sont en place dans le
domaine de la sécurité des informations et de la protection des messages et
des services. Bien que des processus métiers de protection aient été amorcés, la sensibilisation dans l’entreprise est toujours insuffisante et il n’existe
pas encore de politique de protection de l’information à l’échelle de l’entreprise.
256
13 Annexe : Modèle de maturité SOA
Points de contrôle
•
Des mesures à l’échelle de l’entreprise ont-elles été prises pour gérer les
risques dans le domaine de la sécurité des informations ?
•
L’entreprise est-elle au courant des risques encourus dans le domaine de
la sécurité des informations ?
D : Proactive
L’entreprise utilise une politique de protection des informations à l’échelle
de l’entreprise détaillant tous les risques et mesures possibles concernant la
protection des messages et des services. Les incidents en termes de sécurité
sont analysés et pris en compte dans l’élaboration de la politique de protection de l’information. Les directeurs métier et processus sont responsables
des incidents de protection des informations.
Points de contrôle
•
L’entreprise est-elle pleinement au courant des risques qu’elle prend dans
le domaine de la sécurité des informations ?
•
L’entreprise a-t-elle à sa disposition une politique de sécurité des informations à l’échelle de l’entreprise ?
•
La responsabilité de la sécurité des informations est-elle intégrée à l’entreprise ?
•
Des mesures ont-elles été prises afin de protéger les processus métiers ?
13.18 Compétence SOA des informaticiens
A : Basique
Un niveau basique d’expertise a été établi au sein du service informatique.
Les informaticiens connaissent la SOA.
Points de contrôle
•
Un nombre suffisant d’informaticiens connaissent-ils la SOA ?
•
Un nombre suffisant d’informaticiens ont-ils accès à la vision SOA et aux
principes de l’entreprise ?
B : Modérée
Les informaticiens ont établi un niveau plus avancé d’expertise au moyen
d’une application pratique dans les projets. Les informaticiens peuvent appliquer la SOA à leur travail. En moyenne, tous les informaticiens influencés par
la SOA ont travaillé sur la SOA au cours d’un projet.
257
SOA for Profit
Points de contrôle
•
Des informaticiens en nombre suffisant ont-ils accumulé une expérience
pratique de la SOA ?
C : Expérimentée
Les informaticiens ont acquis une expertise exhaustive en matière de SOA.
Cette expérience s’est étoffée au cours de différents projets. Les informaticiens maîtrisent la SOA.
Points de contrôle
•
Un nombre suffisant d’informaticiens ont-ils une expérience pratique de
SOA sur plusieurs projets ?
•
Les informaticiens ont-ils suivi des séminaires sur la façon dont l’entreprise traite la SOA ?
13.19 Compétence SOA des professionnels métiers
A : Basique
Un niveau basique d’expertise a été atteint. Les professionnels métiers
connaissent la SOA.
Points de contrôle
•
Un nombre suffisant de professionnels métiers connaissent-ils la SOA ?
•
Un nombre suffisant de professionnels métiers ont-ils accès à la vision et
aux principes SOA de l’entreprise ?
B : Modérée
Les professionnels métiers ont établi un niveau plus avancé d’expertise au
moyen d’une application pratique dans les projets. Les professionnels
métiers peuvent appliquer la SOA à leur travail. En moyenne, tous les professionnels métiers influencés par la SOA ont travaillé sur la SOA au cours
d’un projet.
Points de contrôle
•
Un nombre suffisant de professionnels métiers ont-ils accumulé une expérience pratique de la SOA ?
258
13 Annexe : Modèle de maturité SOA
C : Expérimenté
Les professionnels métiers ont établi une expertise exhaustive en matière de
SOA. Cette expérience s’est étoffée au cours de plusieurs projets. Les professionnels métiers maîtrisent la SOA.
Points de contrôle
•
Un nombre suffisant de professionnels métiers ont-ils une expérience
pratique de la SOA sur plusieurs projets ?
•
Les professionnels métiers ont-ils suivi des séminaires sur la façon dont
l’entreprise traite la SOA ?
13.20 Connaissance et état d’esprit SOA des informaticiens
A : Sensibilisation limitée
Les gens connaissent la SOA de façon sporadique au sein du service informatique. Le terme n’est pas inconnu pour la plupart d’entre eux, mais ils
n’arrivent pas à le cerner et encore moins à identifier les avantages qu’ils
pourraient en tirer.
Points de contrôle
•
La majorité du service informatique connaît-elle la SOA ?
B : Sensibilisation au niveau de l’organisation du service
Au sein du service informatique, les gens sont très sensibilisés à la SOA et
aux avantages qu’elle peut apporter. Toutefois, le scepticisme est de mise
ainsi qu’une réticence vis-à-vis des conséquences de la mis en œuvre de la
SOA.
Points de contrôle
•
La majorité du service informatique reconnaît-elle les avantages de la SOA
pour son propre service ?
•
La majorité du service informatique connaît-elle de façon exhaustive la
SOA ?
C : État d’esprit SOA
La SOA profite d’un large soutien au sein du service informatique. Les avantages et conséquences de la mise en œuvre sont clairs et acceptés de manière
générale. Le service informatique a hâte d’en tirer les bénéfices.
259
SOA for Profit
Points de contrôle
•
La majorité du service informatique reconnaît-elle les avantages de la SOA
pour son propre service ?
•
La mise en œuvre de la SOA au sein du service informatique s’appuie-telle sur une large base de soutien ?
13.21 Connaissance et état d’esprit SOA des professionnels métiers
A : Sensibilisation limitée
Les gens connaissent la SOA de façon sporadique au sein du service métiers.
Le terme n’est pas inconnu pour la plupart d’entre eux, mais ils n’arrivent
pas à le cerner et encore moins à identifier les avantages qu’ils pourraient
en tirer.
Points de contrôle
•
La majorité du service métier connaît-elle la SOA ?
B : Sensibilisation au niveau de l’organisation du service
Au sein du service métier, les gens sont très sensibilisés à la SOA et aux avantages qu’elle peut apporter. Toutefois, le scepticisme est de mise ainsi qu’une
réticence vis-à-vis des conséquences de la mis en œuvre de la SOA.
Points de contrôle
•
La majorité du service métier reconnaît-elle les avantages de la SOA pour
son propre service ?
•
La majorité du service métier connaît-elle de façon exhaustive la SOA ?
C : État d’esprit SOA
La SOA profite d’un large soutien au sein du service métier. Les avantages et
conséquences de la mise en œuvre sont clairs et acceptés de manière générale. Le service métier a hâte d’en tirer les bénéfices.
Points de contrôle
•
La majorité du service métier reconnaît-elle les avantages de la SOA pour
son propre service ?
•
La mise en œuvre de la SOA au sein du service métier s’appuie-t-elle sur
une large base de soutien ?
260
13 Annexe : Modèle de maturité SOA
13.22 En guise de conclusion
L’utilisation de la SOA implique plusieurs facteurs. Dans la présente Annexe,
nous en avons défini 20, chacun suivant son propre parcours de développement. Ils sont bien trop nombreux pour être traités tous à la fois par une
entreprise. Le modèle de maturité SOA est un outil servant à concentrer l’attention sur des domaines spécifiques (un à la fois). Grâce aux points de
contrôle servant à se concentrer davantage sur le développement de chaque
secteur, il est possible de déterminer le statut d’une entreprise. Calquer l’entreprise sur le modèle de maturité peut permettre d’identifier les secteurs clé
qui doivent être mis en avant dans un futur proche et de clarifier dans quelle
mesure cela doit être fait.
261
References
Acharya, Amit et al., SOA Foundation Service Creation Scenario, IBM Redbook,
2006, http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpieceAbstracts/
sg247240.html?Open
Ang, Jenny et al., SOA antipatterns, 2005, http://www-128.ibm.com/developerworks/webservices/library/ws-antipatterns/
Arsanjani, Ali et al., The SOA solution stack, an architectural reference model, 2005
Bartlett, Christopher et Sumantra Ghoshal, Managing Across Boarders – the transnational solution, Harvard Business School Press, 2002
Belbin, Meredith, Management Teams, Oxford, 2004
Berg, Martin van den et Marlies van Steenbergen, Building an Enterprise Architecture Practice, Springer, 2006a
Berg, Martin van den et Erik van Ommeren, Verbied services! De verplichte relatie
tussen EA en SOA, Informatie, octobre 2006b
Bieberstein, Norbert, Human Services Bus Stays Human at http://soaprojectmanager.com, le 22 décembre 2006.
Bieberstein, Norbert et al., Impact of service-oriented architecture on enterprise
systems, organizational structures, and individuals, IBM Systems Journal 44-4,
2005a, http://www.research.ibm.com/journal/sj/444/bieberstein.html
Bieberstein, Norbert et al., Service-Oriented Architecture Compass: Business Value,
Planning and Enterprise Roadmap, Prentice-Hall, 2005b
Bieberstein, Norbert et al., Transformational Impact of SOA on Corporations Challenges to IT Systems, Organization Structures and Individuals, IBM Systems
Journal, Vol. 44-4, 2005c
Bloem, Jaap et al., Making IT Governance Work in a Sarbanes-Oxley World, Wiley,
2005
Bloomberg, Jason, When Not to Use an SOA, Zapflash-02162004, 2004, www.zapthink.com
Broadbent, Marianne et Peter Weill, Leading Governance Business and IT Processes, ITEP Findings, 2002
Brown, Carol et Jeanne W. Ross, The IT Organization of the 21st Century: Moving
to a Process-Based Orientation, CISR WP No. 306, MIT Sloan, 1999, http://web.
mit.edu/cisr/working%20papers/cisrwp306.pdf.
Buckingham, Marcus, Now, Discover your Strengths, The Free Press, 2001
CBDi Journal, SOA Fundamentals, 2005, http://www.cbdiforum.com/
CIO Asia, The Truth about SOA, 2006, http://cioasia.com/ShowPage.aspx?pagetype
=2&articleid=4021&pubid=5&issueid=98
263
CIO Insight, Case Study: Starwood Hotels Uses SOA to Improve Guest Services and
Cut Costs, 2006, http://www.cioinsight.com/article2/0,1397,1954594,00.asp
Colan, Mark, Five entry points, 2006, http://www.xmlone.org/xmlasia2006/slides/
ibm-colon-5-entry-points-for-soa.pdf
DiMare, Jay et al., The business Value of SOA, IBM Institute for Business Value,
2006, www.ibm.com
Dueck, Gunther, Wild Duck, Empirische Philosophie der Mensch-Computer-Vernetzung, Markus Kaminski, 2005
Friedman, Thomas, The World Is Flat, Allen Lane, 2005
Galbraith, Jay R., Designing the Global Corporation, Jossey-Bass, 2000
Gartner, Introduction to Service-Oriented Architecture, Gartner Research IDnumber SPA-19-5971, 2003
Gartner, A Portal May Be Your First Step to Leverage SOA, Gartner Research IDnumber G00130149, 2006a
Gartner, Maximize Your SOA Investment via Policy Enforcement: Gartner Research
ID-number G00141010, 2006b
Gartner, Sample Governance Mechanisms for a Service-Oriented Architecture,
Gartner Research ID-number G00139465, 2006c
Gartner, Service-Oriented Architectures Craves Governance; Gartner Research IDnumber G00135396, 2006d
Gartner, SOA: Where do I Start?, Gartner Research ID-number G00130149, 2006e
Ghoshal, Sumantra et Christopher Bartlett, The Individualized Corporation, Harper
Business Books, 1999
Heffner, Randy, Survey Data Says: The Time For SOA Is Now, Forrester Research,
2006
Herrington, Jack, Cook up your own with these recipes, 2006, http://www-128.ibm.
com/developerworks/opensource/library/os-php-dhtml1/
High, Rob, Stephen Kinder, Steve Graham, IBM’s SOA foundation, 2005, http://
download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/ws-soawhitepaper.pdf
Hoogervorst, Jan, Enterprise Governance & Architectuur, SDU, 2006
IBM, Collaborations and communications, On Demand Workplace, 2005a, http://
www.ibm.com/ibm/responsibility/people/communications/ondemand-workplace.shtml
IBM, IBM SOA Foundation, Providing what you need to get started with SOA, 2005b,
IBM, Entry Points into SOA, 2006a, http://akamai.infoworld.com/spotlights/soa/
SOA_Entry_Points.pdf
IBM, SOA From A Business Centric Perspective, 2006b, http://www.infoworld.com/
event/soa/docs/IE_051606_Sandy_CARTER_IBM_Websphere_Marketing.ppt
264
IBM, SOA Governance, 2006c, http://www306.ibm.com/software/solutions/soa/gov/
IBM Global Business Services, Component business models, Making specialization
real, 2005, www.ibm.com
IBM Global Business Services, Expanding the Innovation Horizon, the Global CEO
Study 2006, 2006a, www.ibm.com
IBM Global Business Services, Service Oriented Architecture, a practical guide to
measuring return on that investment, 2006b, www.ibm.com
IFAC, Enterprise Governance, Getting the Balance Right, 2004, www.ifac.org
IT Governance Institute, Board Briefing on IT Governance, 2003, www.itgi.org
Kaplan, Robert et David Norton, Strategy Maps, Harvard Business School Press,
2004
Koomen, Tim et al., TMap Next, for result-driven testing, Tutein Nolthenius, 2006
Macehitter, Neil et Neil Ward-Dutton, On IT-business alignment, 2005, www.
mwdadvisors.com
Macehitter, Neil et Neil Ward-Dutton, Service-Oriented Architecture: handle with
care, 2005, www.mwdadvisors.com
O’Reilly, Tim, What is Web 2.0, 2005, http://www.oreillynet.com/pub/a/oreilly/tim/
news/2005/09/30/what-is-web-20.html
Rogue Wave, White Paper, The business case for SOA, 2006, www.roguewave.com
Smit, Gerard, et al., Face-to-face, SOE and what are you doing with SOA, 2006
http://www.nl.capgemini.com/m/nl/f2f/service_oriented_enterprise/02_Alliances.pdf
Smits, Daniel, Succes met IT Governance, Sogeti, 2006
Wagter, Roel et al., Dynamic Enterprise Architecture, How to Make It Work, Wiley,
2005
Weblayers, Policy Based Governance for the Enterprise, White paper, 2005a, www.
weblayers,com
Weblayers, SOA Governance, Introduction, White paper, 2005b, www.weblayers.com
Weill, Peter et Jeanne W. Ross, IT Governance: How Top Performers Manage IT
Decision Rights for Superior Results, Harvard Business Press, 2004
Wikipedia, www.wikipedia.org
265
Index
A
bus de services d’entreprise (ESB) 81
administrateur registre 144
bus de services humains (HSB) 126
administrateur système et base de
business model 98, 101, 105
données 142
agilité 55
C
alignement métier (domaine de matu-
cartographie
rité SOA) 154
domaine métier 102
analyse des risques d’un produit 200
potentiels 103, 109
analyste d’entreprise 141
CBM 111
animateur des transferts de compéten-
centre d’excellence 91
ces 142
approche
chaîne de valeur 106
champion du service métier 139
bottom-up 177
chaos (cas de figure) 160
middle-out 177
chiffre d’affaires (augmentation du) 32
top-down 177
choix de base 173, 175
architecte d’entreprise 137
COB 126
architecture
COE 91
de domaine 78
collaboration 181
d’entreprise 74
Component Business Modelling (CBM)
de démarrage projet 83, 94
111
de référence 79
concepteur de flux de processus 143
développement 153
configuration dispersée 48, 125
en tuyaux de poêle 100
conformité 32
en silos 100
couches 48
orientée services (SOA) 19
cycle de vie des services (gestion du)
utilisation de l’ 153
71
associés (processus) 107, 108
asynchrone 46
D
décomposition et réutilisation
(domaine de maturité SOA) 155
B
BDTM 197, 199, 200, 208
déployeur de services 142
base (choix de) 173, 175
destruction proactive 55
bottom-up (approche) 177
développement
budgétisation et planification (domaine
de maturité SOA) 155
bus d’orchestration et de collaboration
(COB) 126, 127
avec architecture (processus DYA) 74
sans architecture (processus DYA) 75
développement de nouveaux produits
32
267
développeur de services 141
M
dialogue stratégique (processus DYA)
matrice Gain/Facilité 115
74, 75
maturité 150
domaine (architecture de) 78
modèle 163
niveau 151
point de contrôle 152
E
EAI 48
secteurs clés 152
écueils 215
middle-out (approche) 177
engagement et motivation (domaine de
modèle de maturité 163
maturité SOA) 152
modèles industriels 121
entreprise (architecture d’) 137
entreprise dynamique (DYA) (architecture d’) 74
entreprise orientée services 99, 100,
N
normes 49
nouveaux produits (développement de)
123
ESB 81
32
O
optimisation métier 97
outils architecturaux (domaine de
F
façonneur d’outils 142
maturité SOA) 154
feuille de route 171
flair développé 231
P
plan d’urbanisme 78
G
points d’entrée 179
gestion de la qualité (domaine de matu-
points de contrôle de niveaux de matu-
rité SOA) 154
gestion des tests par l’activité (BDTM)
199
gestion du portefeuille de services
(domaine de maturité SOA) 154
gouvernance 61, 66, 84, 89, 92
rité 152
portefeuille de services 68
potentiels 57, 100
potentiels d’activité 100
processus associés 107, 108
processus métiers (mis en œuvre) 155
d’entreprise 66
Project Start Architecture (PSA) 83, 94
mécanismes 94
projet pilote 175
projets de disponibilité 178
H
HSB 126
Q
qualité (gestion de la) (domaine de
maturité SOA ) 154
I
information comme service 186
intégration d’applications d’entreprise
(EAI) 48
268
qualité du service 73
R
responsable projet 143
RACI 85
stratégie de test 198, 204
RAEW 85
souplesse accrue 32
Rational Unified Process 49
souplesse du système d’information
réduction
(domaine de maturité SOA) 155
des coûts 32
spécialiste sécurité 141
des risques 32
stratégie 89
réference (architecture de) 79
stratégie en cascade 108, 117
registre des services 73
régression (test de) 206
T
relation avec les projets (domaine de
technologie et standards (domaine de
maturité SOA) 153
responsable du registre de services 140
maturité SOA) 155
test 196, 197
réutilisation 51, 53, 191
approche 197
risques 195
environnement 209
rôles 137, 139
stratégie 198, 204
rôles et responsabilités (domaine de
maturité SOA) 153
testeur d’interopérabilité 144
testeur de l’intégration des services
142
TMap 197, 198
S
sécurité de l’information (domaine de
maturité SOA) 156
top-down (approche) 177
tuyaux de poêle (architecture en) 100
services 46, 109, 128, 129, 186
architecturaux (processus DYA) 74
U
gestion du cycle de vie 71
utilisation de l’architecture 153
qualité 73
réutilisation 51, 53, 191
V
silos 112
vision d’entreprise 32
SOA
vision de l’architecture SI (domaine de
achetée 65
maturité SOA) 154
administrateur système 143
brute 65
W
compétences (domaine de maturité
Web 2.0 131, 132
SOA) 156
état d’esprit et connaissances
X
(domaine de maturité SOA) 156
XML 46, 193
gouvernance 61, 66, 84, 89, 92
maturité seceurs clés 150, 152
redondante 65
269
À propos d’IBM
Chez IBM, nous nous efforçons d’être les leaders en matière d’invention, de développement et de fabrication des technologies de l’information les plus avancées du
secteur. Cela passe par les systèmes informatiques, les logiciels, les systèmes de
stockage et la micro-électronique. Nous transformons ces technologies avancées en
valeur pour nos clients grâce à nos solutions professionnelles, services et activités
de conseil dans le monde entier. IBM suit un business model unique et ciblé : l’innovation. IBM définit sa vision en s’appuyant sur les problèmes, processus et exploitations rencontrés dans divers secteurs, puis invente et met en pratique une technologie pour aider ses clients à résoudre leurs problèmes compétitifs et à gérer
l’activité la plus difficile. Tout en continuant à vouloir garder le leadership en matière
de développement de technologies de pointe, de produits et d’offres de services
associés, nous évaluons sans cesse notre position en fonction de l’aide apportée à
nos clients pour résoudre leurs problèmes les plus urgents et les plus importants.
271
À propos de Sogeti
Sogeti, leader en matière de services informatiques et de technologie de proximité,
offre aux grandes entreprises une large gamme de services professionnels de proximité dans les domaines du High Tech Consulting et de la technologie de l’information
par le biais de ces trois domaines complémentaires :
•
Services d’application ou intégration de systèmes.
De la conception à l’entretien de systèmes d’informations : conseil, architecture,
support, développement, intégration, test et entretien des éléments
d’application.
•
Services d’infrastructure ou gestion d’intégration et administration de systèmes.
De l’intégration d’infrastructures techniques à la mise en œuvre de systèmes
informatiques : conseil, architecture technique, ingénierie, intégration, installation et administration de systèmes et réseaux, gestion de mise en œuvre et assistance utilisateur.
•
Haute Technologie ou Conseil de Haute Technologie.
Développement et Recherche Extérieurs et Conseil en Innovation. R&D technique et scientifique, conception mécanique, développement de systèmes complexes.
Sogeti emploie plus de 18 000 professionnels en France, en Belgique, au Danemark,
au Luxembourg, en Allemagne, aux Pays-Bas, en Espagne, en Suisse, en Suède, au
Royaume-Uni et aux États-Unis.
Pour plus de renseignements, veuillez consulter notre site : www.sogeti.com
273
À propos des auteurs
Martin van den Berg
Martin van den Berg occupe un poste d’Architecture Service Line Manager chez Sogeti
Nederland B.V. À ce titre, il est responsable du
développement des services d’architecture et
de l’expertise. En outre, il oriente les entreprises lors de la professionnalisation de l’architecture d’entreprise et de la mise en œuvre de
l’architecture orientée services. Il est l’un des
fondateurs de la DYA (architecture dynamique) ainsi que le coauteur de « Dynamic
Enterprise Architecture, How to make it
work » et « Building an Enterprise Architecture Practice ». Martin van den Berg est également le président du département architecture de la Dutch Computer Society. Martin a
publié de nombreux articles et est un intervenant recherché pour les séminaires sur l’architecture.
[email protected]
Norbert Bieberstein
Norbert Bieberstein travaille pour l’organisation SOA Advanced Technologies de IBM et
est responsable de la publication et de la
communication de sujets en rapport avec la
SOA partout dans le monde. Il a accumulé des
expériences directes de première main à partir de projets client dans diverses industries
s’efforçant de migrer vers des solutions
basées sur la SOA. Norbert a publié plusieurs
articles sur les sujets associés à SOA, coordonné le numéro 44-4 consacré à la SOA de
IBM Systems Journal, et a été l’auteur principal de Service-Oriented Architecture Compass
(ISBN 0-13-187002-5). Avant cela, il a été le
coauteur de deux livres rouges (redBooks)
d’IBM : Introduction to Grid Computing with
Globus (SG24-6895-01) et Enabling Applications for Grid Computing with Globus (SG246936-00), et a publié l’ouvrage CASE-Tools
(ISBN : 3446175261). Il a commencé chez IBM
en qualité de conseiller en technologie logicielle dans les laboratoires de développement
de logiciels en 1989. En tout, son expérience
dans la technologie de l’information et les
sciences informatiques s’élève à 27 ans. Avant
d’être chez IBM, il a travaillé en tant que
développeur d’applications chez un fournisseur de logiciels de plus petite envergure et
274
en tant que programmateur scientifique à
l’Université de Technologie d’Aachen
(RWTH), où il a également obtenu son Mastère en mathématiques et en géographie. Il
vient de terminer un programme de Corporate MBA au Henley Management College au
Royaume-Uni.
[email protected]
Per Björkegren
Per Björkegren est l’un des principaux Architectes d’Entreprise et stratégistes informatiques en Suède. Il est chef de la pratique de
l’Architecture et de la Gouvernance Informatique chez Sogeti Suède, développant les
offres de services et intervenant dans des
séminaires ouverts. Per est le fondateur et
président de SWEAN (Swedish Enterprise
Architecture Network), qui compte à ce jour
environ 350 membres. Per passe la majorité
de son temps « sur le terrain » assistant de
nombreuses sociétés en Suède concernant le
développement d’activités basées sur l’informatique, l’architecture d’entreprise et la gestion informatique. Per a une connaissance
solide de l’informatique, allant du développement logiciel à l’architecture en passant par
la gestion commerciale et un ensemble étendu
de missions de développement d’offres de
services au niveau mondial de Capgemini.
[email protected]
Jean-Marc Gaultier
Jean-Marc Gaultier est le Vice-président responsable de l’alliance du Groupe Sogeti avec
IBM. Il a une connaissance étendue des ventes
internationales dans le domaine de l’informatique avec une expérience en gestion des ventes allant des tests de contrôle logiciel, aux
services de proximité aux clients locaux (Local
Professional Services) et à l’externalisation, en
Europe et aux États-Unis.
Actuellement, Jean-Marc aide le Groupe
Sogeti à développer son offre, ses compétences et ses ventes tournant autour de la technologie IBM.
[email protected]
Lon L. Holden
Lon est Worldwide Solutions Manager au sein
du groupe IBM Software. À ce titre, Lon est
responsable de la collaboration avec des intégrateurs de systèmes pour développer le plus
efficacement possible la technologie IBM
dans leurs offres de solution. L’accent est mis
sur l’identification des domaines où la technologie entre en jeu pour fournir une valeur
ajoutée importante aux clients, tout en proposant une différentiation concurrentielle dans
les offres de l’intégrateur. Lon a une grande
expérience dans le secteur du conseil informatique comprenant le développement logiciel, la méthodologie et la gestion de projet.
Lon est spécialisé dans la compréhension et
l’application de la technologie dans un
contexte commercial.
[email protected]
Manuel de Juan
Manuel de Juan est Directeur Technique et
membre du Bureau d’Innovation Informatique (IT Innovation Office) chez Sogeti Espagne. Dès ses débuts dans l’informatique, il a
consacré ses efforts professionnels à résoudre l’intégration entre les systèmes, que ce
soit en qualité de développeur logiciel, d’analyste ou de directeur de projet. Lorsqu’on lui
demande quelles sont ses opinions politiques,
il répond toujours : « Je suis au centre comme
les intergiciels ».
[email protected]
Tim Koomen
Tim Koomen est Directeur et Stratège de
l’équipe de R&D du département de Test de
Sogeti Netherlands B.V., et s’occupe, entre
autres, des tests en environnements agiles
(DSDM, RUP), de l’Amélioration de Processus
de Test, des stratégies de test et des tests SOA.
Il est le coauteur du livre TPI, publié en hollandais, anglais, allemand et japonais, corédacteur du livre TMap Test Topics, publié
en hollandais et en anglais, coauteur de TMap
Next (hollandais, anglais et allemand (à paraître bientôt)) et assiste à de nombreuses
conférences (Eurostar ‘97-’06, ICSTest (4x),
Quality Week Europe ‘99, Congrès SQE 2000,
Quality Week 2000, Conquest 2001, StarEast
2003) et formations en Europe et aux ÉtatsUnis. En 2003, il a reçu le Prix d’Excellence de
Test Européen (European Testing Excellence
Award) pour son travail sur TPI, TMap et les
tests en général.
[email protected]
Craig Mayer
Craig Mayer est Directeur chez Sogeti USA,
fort de plus de vingt-cinq ans d’expérience au
niveau exécutif international et national en
matière de gestion, de technologie de l’information et d’exploitation dans diverses industries. Son expérience première concerne l’alignement de l’entreprise et de la stratégie
technologique d’information ; il possède aussi
une connaissance approfondie de la réorganisation d’entreprise et la reconfiguration.
Outre ses compétences et son expérience en
matière d’Architecture orientée services
remontant à la fin des années 1990, il est également très compétent en matière d’efficacité
et d’intégration de processus métiers, Sarbanes-Oxley – CobIT – ITIL évaluation et
conformité, kaizen et gemba kaizen (amélioration permanente), et de tests de logiciels
basés sur la qualité/les risques. Craig est titulaire d’un doctorat (ABD) en anthropologie de
l’Université méthodiste du Sud (Dallas,
Texas).
[email protected]
Bruno Rizzi
Bruno Rizzi est un Directeur SOA chez
SOGETI AS France pour le Service des Télécommunications et de l’Industrie. Il est l’un
des créateurs de l’offre SOA Sogeti en France.
Sa riche expérience concerne l’informatique,
y compris le développement logiciel, la qualimétrie, la gestion de projet et l’architecture. Il
a travaillé en qualité d’expert JEE pour plusieurs grandes sociétés françaises. Bruno partage désormais son temps entre le développement de l’offre SOA en entreprise et le conseil
en architecture des clients de Sogeti.
[email protected]
275
Gonzalo Rodríguez Pérez
Gonzalo Rodríguez Pérez est conseiller en
informatique chez Sogeti Espagne. Fort de
plus de dix ans d’expérience en conseil informatique, il occupe plusieurs fonctions : architecte logiciel, directeur de projet, concepteur
et développeur. Il est responsable de l’évaluation d’opportunités SOA chez Sogeti et coordonne la base de connaissance SOA pour les
architectes et analystes de Sogeti en Espagne.
En réalité, Gonzalo est investi dans un Projet
SOA codirigé avec IBM pour Telco Espagne. Il
va s’agir d’un des premiers projets SOA en
production en Espagne.
[email protected]
Erik van Ommeren
Erik van Ommeren est Directeur Innovation
chez Sogeti USA LLC. Il est responsable de
VINT, l’Institut d’Analyse des Nouvelles Technologies de Sogeti, aux Etats-Unis. Il participe
également au développement des pratiques
SOA locales de Sogeti. Il est l’un des pionniers
des initiatives d’Architecture orientée ser­vices
chez Sogeti aux Pays-Bas. Erik a une grande
connaissance en informatique. Son expérience
va du développement logiciel à l’aide de technologies différentes, en passant par l’architecture et la gestion (de projet). Il passe une partie de son temps à conseiller les entreprises
sur des décisions d’architecture, des projets de
transformation et des innovations. Erik est
également formateur, intervenant lors de
séminaires et auteur de plusieurs articles.
Guillaume Schott
Guillaume Schott est directeur technique chez
Sogeti Luxembourg S.A. Il a commencé « à
mettre en œuvre la SOA » en 1998 pour une
grande banque en France en qualité d’architecte pour les postes de travail de nouvelles
succursales. Il a rejoint le bureau du Luxembourg en 2000 et participe à de nombreuses
mises en œuvre de systèmes de banque en
ligne multivoie en qualité d’architecte principal. Ces projets, actuellement en cours de production, intègrent des systèmes hétérogènes
tels que les ordinateurs principaux, systèmes
ouverts, exposent et orchestrent des services et
distribuent des informations via les canaux
Internet, Portable et Vocal.
[email protected]
Gérard Smit
Gérard Smit est Executive IT Architect (certifié) chez IBM pour le compte d’une grande
banque. Sa responsabilité et son expérience
principales tournent autour de la stratégie et
du changement, l’architecture et la technologie. Outre cela, il est également l’un des membres fondateurs et cofondateur du conseil
d’expert technique BeNeLux affilié à l’Académie de technologie IBM, pilier de l’équipe de
direction SOA et vice-président de la Grid
Community of Practice. Gérard est titulaire
d’un diplôme d’ingénieur en informatique
commerciale et d’un Mastère Téremsc en
télématiques d’entreprise.
[email protected]
[email protected]
Philippe Ravix
Philippe Ravix est architecte SI et SOA Service Line Manager chez Sogeti France. Il est
responsable du développement de services
d’architecture chez Sogeti. Il conseille les
entreprises sur des décisions d’architecture
et assiste de nombreuses grandes sociétés
dans le cadre de leurs projets de transformation. Philippe est également formateur, intervenant sur des événements SOA et auteur de
documents de présentations techniques.
[email protected]
Michiel Vroon
Michiel Vroon est Solution Development
Manager chez Sogeti Netherlands B.V. Il a
commencé comme préparateur et directeur
d’unité de tests pendant 2 ans. Il est le
co­auteur de TMap Next (en hollandais, anglais
et allemand) (à paraître bientôt) et de « Integrated Test Design & Automation: Using the
TestFrame method », traduit en Hollandais et
en Anglais. Michiel est professeur et présentateur. Il écrit souvent des articles sur les tests
logiciels. Il tient un rôle prédominant au sein
de la communauté de test Hollandaise Test­
net.
[email protected]
276
Sogeti Pays-Bas Martin van den Berg
Sogeti USA Erik van Ommeren
IBM Software Group Allemagne Norbert Bieberstein
Une contribution pratique et
pragmatique à l'évolution de la
SOA en tant qu'approche architecturale créatrice de valeur pour
l'entreprise. Les différentes visions et les considérations informatiques complètes établies concernant la SOA s'appuient sur
des exemples réels et convaincants. Ce document constitue un
guide prêt à l'emploi pour adopter et mettre en œuvre une SOA.
C’est un document de référence
exceptionnel pour toute personne désirant passer à un niveau supérieur d’alignement de
l’informatique d’entreprise et du
métier grâce à la SOA.
Henrik Jacobsson
Shell
Mon intérêt n’a cessé de croître
au fur et à mesure de ma lecture
du manuscrit… conclusion : «ça
valait le coup» ! L’approche
business, utilisateurs et organisation que les auteurs ont
privilégiée est très pertinente.
Malgré le luxe de détails on n’est
pas submergé de considérations
techniques : un des gros avantages de ce livre ! Un modèle et
une méthode pratiques de mesure de la maturité sont présentés, et la liste finale de références
est très complète et à jour. Si
vous voulez savoir pourquoi je
préfère la définition Bieberstein
de la SOA, lisez le livre par vousmême. En ce qui me concerne,
aucun regret…
Dr. Jan Peter de Valk
ING
SOA
Guide du manager pour une Architecture Orientée Services réussie
L’architecture orientée services (SOA) est en train de devenir
l’architecture informatique dominante, ce qui a des implications
considérables pour le fonctionnement des organisations.
Lentement mais sûrement, l’informatique gagne en maturité et
devient ce support à la fois flexible, stable et fiable dont toute
entreprise a besoin. Dans le même temps, l’informatique revient
en force dans les processus d’innovation au sein de l’entreprise.
Pour toute organisation, la SOA constitue à cet égard un pas
décisif dans la bonne direction à condition de ne pas en faire
une simple question de technologie. Bien sûr, les défis
technologiques sont importants à relever, mais l’apport
essentiel de la SOA se situe ailleurs : une prise en compte
globale de la façon dont l’informatique peut devenir l’élément
clé du succès de toute stratégie d’entreprise.
SOA for Profit dévoile la nature de la SOA et illustre la valeur
ajoutée qu’elle apporte. Cet ouvrage pratique et pragmatique
rend les modèles et les concepts de la SOA intelligibles grâce à
une approche clé en main directement applicable avec profit à
vos projets. Il met en avant l'importance de la gouvernance et
de l'architecture informatiques et démontre qu'une vision
élargie de la SOA est essentielle pour en tirer tous les bénéfices
possibles. Ce livre raccroche l'informatique au management
grâce à des outils et à un langage communs qui rendent
possible le dialogue stratégique que l'on retrouve à la base de
toute informatique orientée métiers.
Écrit par une équipe d'auteurs de Sogeti et d'IBM, SOA for
Profit est un livre concret, tiré d'une longue expérience
d'entreprises et de projets bien réels.
SOA for Profit
Yves Caseau
Bouygues Telecom
SOA for Profit
for Profit
Avec les contributions de
Per Björkegren Sogeti Suède •
Jean-Marc Gaultier Sogeti USA •
Lon Holden IBM Software Group
USA • Manuel de Juan Sogeti
Espagne • Tim Koomen Sogeti
Pays-Bas • Craig Mayer Sogeti USA
• Philippe Ravix Sogeti France •
Bruno Rizzi Sogeti France •
Gonzalo Rodriguez Sogeti
Espagne • Guillaume Schott Sogeti
Belux • Gerard Smit IBM Pays-Bas •
Michiel Vroon Sogeti Pays-Bas
Van den Berg
Van Ommeren (dir.)
Bieberstein
Ce livre est sans conteste le
meilleur livre que j’aie lu sur la
SOA. C’est un livre concret, qui
traite et relie les différents
aspects de cette approche SOA,
depuis la stratégie et les enjeux
métiers jusqu’à la conduite du
changement et des rôles des collaborateurs. Les chapitres sur la
gouvernance et sur préparation
sont eux aussi les meilleures
contributions que je connaisse
sur ces sujets, avec un équilibre
entre l’explication (en donnant
du sens) et l’application (en restant concret et synthétique).
Contribution majeure qui devrait
être lue par tous les managers
non-informaticiens, ce livre permet de comprendre pourquoi la
SOA est fondamentalement
adaptée aux mutations des
entreprises d’aujourd’hui à condition de faire profondément
évoluer leur façon de travailler.
Le style est franc et direct, avec
une pointe d’humour, ce qui en
fait une lecture agréable.
Guide du manager pour une
Architecture Orientée Services réussie