SOA for Profit - French version.pdf

Sogeti Pays-Bas Martin van den BergSogeti USA Erik van Ommeren

IBM Software Group Allemagne Norbert Bieberstein

Avec les contributions dePer Björkegren Sogeti Suède •Jean-Marc Gaultier Sogeti USA •Lon Holden IBM Software GroupUSA • Manuel de Juan SogetiEspagne • Tim Koomen SogetiPays-Bas • Craig Mayer Sogeti USA• Philippe Ravix Sogeti France •Bruno Rizzi Sogeti France •Gonzalo Rodriguez SogetiEspagne • Guillaume Schott SogetiBelux • Gerard Smit IBM Pays-Bas •Michiel Vroon Sogeti Pays-Bas

L’architecture orientée services (SOA) est en train de devenirl’architecture informatique dominante, ce qui a des implicationsconsidérables pour le fonctionnement des organisations.Lentement mais sûrement, l’informatique gagne en maturité etdevient ce support à la fois flexible, stable et fiable dont touteentreprise a besoin. Dans le même temps, l’informatique revienten force dans les processus d’innovation au sein de l’entreprise.Pour toute organisation, la SOA constitue à cet égard un pasdécisif dans la bonne direction à condition de ne pas en faireune simple question de technologie. Bien sûr, les défistechnologiques sont importants à relever, mais l’apportessentiel de la SOA se situe ailleurs : une prise en compteglobale de la façon dont l’informatique peut devenir l’élémentclé du succès de toute stratégie d’entreprise.

SOA for Profit dévoile la nature de la SOA et illustre la valeurajoutée qu’elle apporte. Cet ouvrage pratique et pragmatiquerend 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 etde l'architecture informatiques et démontre qu'une visionélargie de la SOA est essentielle pour en tirer tous les bénéficespossibles. Ce livre raccroche l'informatique au managementgrâce à des outils et à un langage communs qui rendentpossible le dialogue stratégique que l'on retrouve à la base detoute informatique orientée métiers.

Écrit par une équipe d'auteurs de Sogeti et d'IBM, SOA forProfit est un livre concret, tiré d'une longue expérienced'entreprises et de projets bien réels.

SOA for ProfitGuide du manager pour une Architecture Orientée Services réussie SOA

for Profit

Van

den

Ber

gV

an O

mm

eren

(d

ir.)

Bie

ber

stei

n

Guide du manager pour uneArchitecture Orientée Services réussie

Ce livre est sans conteste lemeilleur livre que j’aie lu sur laSOA. C’est un livre concret, quitraite et relie les différentsaspects de cette approche SOA,depuis la stratégie et les enjeuxmétiers jusqu’à la conduite duchangement et des rôles des col-laborateurs. Les chapitres sur lagouvernance et sur préparationsont eux aussi les meilleurescontributions que je connaissesur ces sujets, avec un équilibreentre l’explication (en donnantdu sens) et l’application (en res-tant concret et synthétique).Contribution majeure qui de vraitêtre lue par tous les managersnon-informaticiens, ce livre per-met de comprendre pourquoi laSOA est fondamentalementadaptée aux mutations desentreprises d’aujourd’hui à con -dition de faire profondémentévoluer leur façon de travailler.Le style est franc et direct, avecune pointe d’humour, ce qui enfait une lecture agréable.

Yves Caseau Bouygues Telecom

Une contribution pratique etpragmatique à l'évolution de laSOA en tant qu'approche archi-tecturale créatrice de valeur pourl'entreprise. Les différentes vi -sions et les considérations infor-matiques complètes établies con -cernant la SOA s'appuient surdes exemples réels et convain-cants. Ce document constitue unguide prêt à l'emploi pour adop-ter et mettre en œuvre une SOA.C’est un document de référenceexceptionnel pour toute per-sonne désirant passer à un ni -veau supérieur d’alignement del’informatique d’entreprise et dumétier grâce à la SOA.

Henrik JacobssonShell

Mon intérêt n’a cessé de croîtreau fur et à mesure de ma lecturedu manuscrit… con clu sion : «çavalait le coup» ! L’approchebusiness, utilisateurs et organi -sation que les auteurs ontprivilégiée est très per tinente.Malgré le luxe de dé tails on n’estpas submergé de considérationstechniques : un des gros avan -tages de ce livre ! Un modèle etune mé thode pratiques de me -sure de la maturité sont présen -tés, et la liste finale de référencesest très complète et à jour. Sivous vou lez savoir pourquoi jepréfère la définition Biebersteinde la SOA, lisez le livre par vous-même. En ce qui me concerne,aucun regret…

Dr. Jan Peter de ValkING

SOA

for

Pro

fit

SOA for ProfitGuide 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

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

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, Califor-nia 94105, USA.

http://creativecommons.org/licenses/by-sa/3.0/deed.fr

Les auteurs et éditeurs ont apporté tout leur soin à la fabrica-tion 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 dom-mages indirects ou imprévus occasionnés par l’usage des infor-mations 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 posi-tion officielle des entreprises qui les emploient.

�

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, sus-ceptible 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’orienta-tion 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 mana-gers, 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 dif-férentes approches et analyses globales de la SOA s’appuient sur des exem-ples 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’ac-tivité 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 ouver-tes 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), Ber-gisch-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 illus-tration.

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 disponi-bles 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 orga-nisation 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 commu-nauté 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 moder-nes, 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 appro-che 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 tech-niques (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 vous-mê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éveloppe-ments, on voit comment, au fur et à mesure que des standards se sont déve-loppé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éthodolo-gies 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 prati-que pour la conduite réussie de projets de SOA.

Garry Gomersall,Apôtre de la SOA et dirigeant d’entreprise, IBM Software Group

7

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é com-merciale. Alors que nombreux sont ceux qui désigneraient l’ordinateur cen-tral, l’eBusiness ou les standards ouverts comme points d’inflexion ayant modifié de façon spectaculaire notre fonctionnement en tant que départe-ments 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 reli-sant 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 à nou-veau ; l’objectif étant que chaque département au sein de l’équipe informati-que 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 logi-que autrefois. Mais, dans une économie mondialisée qui dépend de plus en plus de la relation symbiotique entre technologie et business, nous ne pou-vons 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 infor-mations 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 entre-prises 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 communi-quer 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 parte-naires 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 streamli-ning à 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 MillsVice-Président Directeur et Directeur du GroupeGroupe IBM Software

11

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 desti-nées à augmenter l’agilité dès le départ et, grâce à une réutilisation systéma-tisé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 colla-boration 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éta-chée des contraintes infrastructurelles et alignée sur les besoins opération-nels. En d’autres termes, l’agilité économique ne peut être atteinte que lors-que l’accent est déplacé du fonctionnel, de la tuyauterie administrative, vers les business processes transfonctionnels qui s’affranchissent des limites pure-ment 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 trans-parente, 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 stra-té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.

12

Ceci dit, je suis plus que conscient des risques que comporte une telle affir-mation. Quand des responsables informatiques commencent à parler de res-tructuration de l’entreprise pour lui donner une plus grande agilité économi-que, 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 prag-matique 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 à surmon-ter 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 SalvadorPrésident Directeur GénéralSogeti

1�

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 gouver-nance, 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 propo-sant 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.

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 beau-coup 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 2007Martin van den BergNorbert BiebersteinErik van Ommeren

1�

1�

Table des matières

1 Débutduvoyage 191.1 Objectif 201.2 Public visé 201.� Structure 21

2 J’enveuxpourmonargent 232.1 Introduction 232.2 Pourquoi la SOA ? 242.� Pourquoi les entreprises choisissent-elles la SOA ? 252.� En quoi puis-je être intéressé ? 322.� Dans quels cas la SOA n’est-elle pas recommandée pour moi ? 412.� Synthèse 41

3 L’essencedelaSOAenseptconceptsdebase 43�.1 Introduction 43�.2 Perception de la SOA 43�.� C’est le bon moment 44�.� Les sept concepts de base de la SOA 45�.� Synthèse 59

4 Gouvernanceouchaos 61�.1 Introduction 61�.2 Pourquoi la gouvernance est-elle essentielle ? 61�.� Qu’est-ce que la gouvernance SOA ? 66�.� La gestion des portefeuilles de services 68�.� Gestion de cycle de vie des services 71�.� Registre des services 73�.7 Architecture d’entreprise 74�.� Comment déployer la gouvernance SOA 84�.� Comment démarrer dans la politique de gouvernance SOA 92�.10 Synthèse 95

5 Repenservotreactivité 97�.1 Introduction 97�.2 Quel est votre business model ? 98�.� D’une entreprise orientée fonctions à une entreprise orientée services 99�.� Éléments d’un business model dynamique 101�.� Comment identifiée les éléments de votre business model dynamique 105�.� De la structure en silos au partage des ressources 112�.7 Comment définir des priorités ? 114�.� Comment les modèles industriels vous aideront-ils ? 121�.� Synthèse 122

6 Uneentrepriseorientéeservices 123�.1 Introduction 123�.2 Un exemple 123�.� Une configuration dispersée mais bien cadrée 125�.� Le bus de services humains 126�.� L’importance du Web 2.0 pour une entreprise orientée services 131�.� Synthèse 133

7 Descollaborateursorientésservices 1357.1 Introduction 1357.2 Rôles SOA 1357.� L’impact sur les collaborateurs 1447.� Synthèse 148

8 CommentseprépareràlaSOA? 149�.1 Introduction 149�.2 Modèle de maturité SOA 150�.� Vingt secteurs clés de la maturité SOA 152�.� Tout ne se fera pas nécessairement en un jour 157�.� Utilisation du modèle de maturité SOA 163�.� Action ciblée 168�.7 Synthèse 169

9 CommentdémarrerlaSOA? 171�.1 Introduction 171�.2 Votre feuille de route SOA 171�.� Les points d’entrée 179�.� Synthèse 194

10 Commentarriveràbonport 19510.1 Présentation 19510.2 Comment définir une stratégie de tests SOA ? 19810.� Les différentes étapes de l’approche BDTM 19910.� Avantages de l’approche BDTM 20810.� L’environnement de test SOA 20910.� Adaptation pendant les tests SOA 21010.7 Synthèse 212

11 Lesdixmeilleureschosesàdirepoursefairerenvoyer 21511.1 « N’en parlons pas au métier » 21511.2 « Faites-moi confiance : la SOA, ça coule de source » 21811.� « L’orientation processus est inutile » 21911.� « Construisons une tour de Babel » 22011.� « Demandons à notre nouvel architecte d’entreprise » 22111.� « Changeons les standards » 22211.7 « Lançons-nous avec la SOA à l’assaut des cibles mobiles » 223

1�

17

11.� « Que mille services éclosent » 22411.� « Orientons-nous services sans architecture » 22511.10 « Migrons tout vers la SOA » 226

12 Levoyagecontinue 22912.1 Destinations futures 23012.2 À condition de… 23312.� Passez à l’action 234

13 Annexe:ModèledematuritéSOA 2351�.1 Présentation 2351�.2 Engagement et motivation 2371�.� Relations avec les projets 2381�.� Rôles et responsabilités 2401�.� Développement de l’architecture 2411�.� Utilisation de l’architecture 2421�.7 Outils architecturaux (méthodologie et logiciels) 2431�.� Gestion de qualité 2441�.� Gestion de portefeuille de services 2461�.10 Vision de l’architecture 2471�.11 Alignement des systèmes d’information sur le métier 2481�.12 Budgétisation et planification 2501�.1� Technologie et standards 2511�.1� Subdivision et réutilisation 2521�.1� Mise en œuvre de processus métiers dans le système d’information 2531�.1� Souplesse du système d’information (infrastructure et applications) 2541�.17 Sécurité 2561�.1� Compétence SOA des informaticiens 2571�.1� Compétence SOA des professionnels métiers 2581�.20 Connaissance et état d’esprit SOA des informaticiens 2591�.21 Connaissance et état d’esprit SOA des professionnels métiers 2601�.22 En guise de conclusion 261

Références 263Index 267Àproposd’IBM 271ÀproposdeSogeti 273Àproposdesauteurs 274

1�

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 prin-cipaux problèmes auxquels sont confrontées aujourd’hui les entreprises qui ont recours à l’informatique ? Comment empêcher que des coûts de mainte-nance de plus en plus élevés paralysent une entreprise ? Comment parvenir à une situation dans laquelle vos délais de mise sur le marché sont suffisam-ment 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 matu-rité 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 change-ments au sein de l’entreprise. Ces services sont ensuite utilisés afin de dévelop-per 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 main-tenance 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 infor-matique ; 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 rela-tions 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.

20

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 illogi-que 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 com-merciaux, directeurs de l’information, gestionnaires de processus, gestionnai-res du changement, directeurs de projets et architectes d’entreprise, qui peu-vent tirer un très large profit de ce document.

•

•

•

•

21

Il est également utile aux personnes régulièrement impliquées dans les pro-jets SOA au sein de l’entreprise telles que les directeurs de produit, architec-tes 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 appro-che 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’en-treprises 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’uti-liser 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 informati-ques. 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’en-treprise. 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.

1 Debut du voyage

22

SOA for Profit

Les chapitres 3 à 7 couvrent en détail les conséquences et conditions préala-bles 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 convenable-ment les services et processus métiers dans lesquels ces services seront uti-lisé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 efficace-ment. 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.

2�

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’ef-ficacité à 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’in-formation 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

2�

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égis-lation et règlements, opportunités de marché, possibilités technologiques, res-pect 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 sou-plesse. 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éri-table 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étermi-ner les systèmes à adapter.

Autre exemple, celui d’un organisme gouvernemental dont la productivité informatique chute à cause de systèmes informatiques toujours plus comple-xes. 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éra-lement 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 pro-cessus métiers doit être exécuté. Lorsqu’il devient nécessaire d’adapter ce pro-cessus, le système doit lui aussi être ajusté, ce qui implique un immense travail

2�

de recherche et de test. Grâce à l’approche SOA, la fonctionnalité peut être divi-sé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é. Lors-qu’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 égale-ment 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’infor-matique. Aujourd’hui, elle donne à la fonction informatique les moyens appro-prié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 servi-ces. 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 objec-tifs 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 com-merciale 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 four-nisseurs 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’impor-tance 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.


2�

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 :

Considérations stratégiques : l’environnement économique dont fait partie l’entreprise est sur le point de changer.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éeL’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 crois-sante 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

1.

2.�.

Chaîne de paiement

Client

Services d’entreprise

Procédé

Application

Procédé

Infrastructure

Application

Figure 2.1 : La chaîne SOA

27

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’entre-prise 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 infor-matique 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écommunicationsQu’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é insuffisanteS’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.


2�

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écommunica-tions. 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éve-loppement : 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éritable-ment le temps d’explorer pour s’assurer que les choses avaient été faites et com-ment. 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éve-loppements 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 productionConsé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) augmen-taient 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ésL’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 deman-des de services, changements dans les services existants, modifications des informa-tions 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.

•

•

•

2�

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 chan-gements é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 mainte-nance 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 produc-tion 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.

GRC

Logique métier Évolution du plan

de tarificationA

Facturation

Entrepôt de données Mise en réseau

Commercialisation


�0

SOA for Profit

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 StarwoodEn 2001, Starwood Hotels a pris conscience que son avenir passait par une archi-tecture orientée services [CIO Insight 2006]. Cette chaîne d’hôtels internatio-nale, qui regroupe des enseignes telles que les hôtels St. Regis, Sheraton, Wes-tin’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 distri-bution 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.

GRC


de tarificationA

WEB


de tarificationA’

Facturation

Entrepôt de données Mise en réseau

Commercialisation

SMS


de tarificationA’’’

IVR

Logique métierÉvolution du plan

de tarificationA’’

Figure 2.3 : Conséquences de l’évolution du plan de tarification

�1

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 informa-tique 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 correspon-dre 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, personnalisa-bles en fonction des besoins et spécificités de chaque hôtel. La fonction « recher-che » de Sheraton peut, par exemple, fournir des informations d’une manière dif-fé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 applica-tions 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 éga-lement à 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 mainte-nance.

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.


�2

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 situa-tion 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 situa-tion 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équen-ces induits par le choix de la SOA. La vision d’entreprise permet de détermi-ner 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’impor-tance, les avantages de la mise en œuvre de la SOA.

Souplesse accrue Capacité au changement supérieureRéutilisation accrue des actifsRéduction du temps d’intégration des systèmesRéduction du temps de mise sur le marché

•

•

•

•

Réduction des coûts Réduction du coût d’intégration des systèmesRé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èmesRé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 revenusCroissance des sources de revenus actuellesMaintien des sources de revenus actuelles

•

•

•

Développement de nouveaux produits

Création de nouveaux services par l’utilisation des systèmes actuels et/ou nouveauxCréation et livraison accélérée de nouveaux produits

•

•

Conformité Transparence accrueExactitude et surveillance accrues

•

•

Tableau 2.1 : Avantages constatés des projets de SOA

��

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’indi-que la conclusion des trois exemples abordés dans la section précédente.

Nécessité de changement de technologie

Environnements patrimoniaux vieillissants/inadaptésCapacité insuffisante, fiabilité réduiteSystè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 souplesLivraison plus rapide de produits et servicesAmé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).

Figure 2.4 : Éléments de la vision d’entreprise SOA

Raisons Avantages

DéfinitionMise en œuvre

Conséquences

Visiond’entreprise


��

SOA for Profit

La vision d’entreprise se compose de cinq éléments : raisons, avantages, défi-nition, conséquences et mise en œuvre. Nous allons maintenant les aborder en détail.

RaisonsLa 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 inca-pable 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 (busi-ness case).

AvantagesL’é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’en-treprise 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 ?•

��

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 com-merciaux ? 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 mar-ché ?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 per-mettre de réduire notre temps de mise sur le marché pour les nouveaux pro-duits ? 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 ? Quel-les 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.

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•


��

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’in-té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 entrepriseLes arguments en faveur de la SOALe point de départLe moment pour commencerLes 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 perfor-mants ?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 domai-nes ê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.

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

�7

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épar-tement 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 informati-que. 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éfinitionLe troisième élément de la vision d’entreprise SOA, le « quoi », est tout aussi important que le « pourquoi » (avantages). Une défini-

tion de la SOA permet de formuler l’architecture spécifique à l’entreprise et d’identifier les aspects requis.

•

•

•

•

•

•

•

•

•

•


��

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 cer-tain nombre de définitions de la SOA.

ConséquencesOutre 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.

Figure 2.5 : 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 demand-eurs 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.

��

Les conséquences ordinaires de la mise en œuvre de la SOA sont les suivan-tes :

Focalisation accrue sur l’effort centré sur le processus.Changement des processus de gouvernance et des processus architectur-aux.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 proces-sus, chefs de service informatique, administrateurs et architectes. Un atelier de méthodologie convient parfaitement pour la création d’une vision d’entre-prise. Différentes personnes œuvrant dans différentes disciplines peuvent être amenées à travailler ensemble pour un objectif commun.

•

•

•

•

•

•

•

•


�0

SOA for Profit

La définition d’une vision d’entreprise peut être encore facilitée en impli-quant 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.

�1

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 four-nisseurs 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 fonction-nalité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 ser-vice. Tôt ou tard, il deviendra donc impossible d’y échapper.

Reste à savoir si vous devez anticiper la SOA ou bien si vous devez simple-ment attendre que la SOA vous prenne de vitesse. La SOA est particulière-ment 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épen-dantes 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 informa-tique 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 radica-lement 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’ar-gent 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-


�2

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’ex-ploration 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.

��

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’architec-ture 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 expli-querons 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 inci-dence 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 informa-tique 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

��

SOA for Profit

CBDI (Component Based Development Integration), utilisent tous une termi-nologie et des modèles différents. Tout ceci trouble considérablement la situa-tion, 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 servi-ces, 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’in-tégration de systèmes et de services Web ; deuxièmement, l’utilisation de l’In-ternet a atteint un seuil critique ; et enfin, sans doute la raison la plus impor-tante, 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.

��

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, nom-bre 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éthodeDans le monde des affaires, vous devez certainement vous mettre d’accord avec le personnel sur la façon de travailler ensemble, convenir de la livrai-son avec les fournisseurs, etc.

�. Utiliser l’existantAvant d’acheter quelque chose de neuf, vous vérifiez préalablement si quelque chose que vous possédez déjà peut convenir.

�. 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.�. 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.�. 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éa-

gir à 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’Entre-prise), l’organisation en couches, l’architecture événementielle, et quelques abréviations courantes dans l’approche SOA.


��

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 sol-licité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’ap-puyant 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 pragma-tique à 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 possibleIci, « 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 rem-placer 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 par-faitement 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

•

•

�7

à 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 ser-vices : 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é commercialeLorsque 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 cer-taine manière, l’informatique est une abstraction technologique de l’entreprise qu’elle assiste. Un processus commercial est soutenu par des processus tech-niques, 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 ren-voie 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


��

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 ser-veurs 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 Inte-gration) 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’excel-lence 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

•

•

��

L’importance des normesLes accords sont des arrangements entre deux parties ou plus. Pour l’utilisa-tion 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 parcou-rant 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 sala-rié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éesPremiè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 tra-duire 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 manage-ment 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.


�0

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, Sarbanes-Oxley 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 perspec-tive 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é infor-matique 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.

•

•

•

�1

Réutilisation de serviceSi 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éutilisationLa 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éutiliserDans 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 ren-tables. 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 quel-que 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éri-ficateur d’orthographe. Tout ceci est disponible dès la création des logiciels.


�2

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 mainte-nance 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 machi-nes et obtenir l’assistance de votre propre personnel, mais préférer externa-liser le service en s’accordant simplement sur le niveau de service à fournir. La réduction des frais de maintenance informatique permettra une amélio-ration 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 choi-sir 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.

��

Réutilisation et services d’infrastructurePour illustrer les différentes façons de penser la réutilisation, nous avons pris l’exem-ple 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.

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’organisa-tion. Toutes les informations ne seront entrées qu’une seule fois et sont accessibles partout où cela est nécessaire.

Figure 3.2 : Services métiers

Enregistrement Patient

RHLabo IRM

Maternité Soins intensifs

Régi

me

et a

limen

tatio

n

Opé

ratio

n

Méd

icat

ion

Dia

gnos

tic

Enre

gist

rem

ent p

atie

nt

… … … …

Réutilisation


��

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.

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 patrimo-niales, des systèmes GRC existants, etc. La vision d’ensemble se trouve en Figure 3.4.

Figure 3.4 : Services et couches dans l’architecture orientée services

Applicationpatrimoniale

Applicationpatrimoniale

Processus métiersLes 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étiersCes 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.

Couches technologiquesSous 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.

Services techniquesLes 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.

Réutilisation

…

Journalisation

Transformation

Autorisations

Sécurité

��

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’entre-prise, 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 dis-ponibles 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éfiLorsque 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 capa-ble 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 aura-t-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 sim-plement 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éces-saire. 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.


��

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 biblio-thè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élio-ration de processus. Avec la SOA, en conjonction avec des méthodes de déve-loppement de logiciel de type industriel, l’informatique peut commencer à automatiser ses propres processus, augmentant ainsi la productivité, rédui-sant 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éli-cate. 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.

�7

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 res-teront suffisamment stables dans les années à venir, seront reliées directe-ment 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é com-merciale 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 comple-xes à la clientèle ou aux partenaires.

Dans un sens, le modèle de « services » d’unités fournissant un service der-riè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 cour-riers é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 infor-matiques 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’informatiqueL’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’in-formatique 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


��

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 évolu-tions probables du secteur dans un proche avenir. Des stratégies distinctes entraîneront des choix différents au plan informatique : ainsi, l’internationa-lisation 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’orienta-tion 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’archi-tecture 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’infor-matique 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 quel-qu’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éne-ments 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’In-ternet avec sa promesse implicite de « réponse immédiate » aux demandes ne fait qu’augmenter cette pression. Cela est comparable au passage du cour-rier papier au courrier électronique : une nouvelle technologie crée de nou-velles 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

��

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 com-merciales au vu d’informations plus justes, et les clients obtiennent les ser-vices 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éne-ments. 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 infor-matiques 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’ave-nir, l’entreprise peut répondre rapidement aux événements quotidiens et s’adapter sans problème à de nouveaux marchés et de nouveaux environ-nements. 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 com-merciales.


�0

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 adap-té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étho-des de gestion des concepts SOA comme essentiels à la réussite.

�1

4 Gouvernance ou chaos

4.1 Introduction

Maintenant que le concept de SOA vous est familier et que vous savez com-ment 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 gouver-nance SOA. L’un des objectifs de la SOA est de réduire les coûts par la réuti-lisation 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 effecti-vement connus), puis de solliciter la réutilisation de ces composants et d’ap-

�2

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’envi-ronnement informatique est devenu de plus en plus complexe, toute modifi-cation 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 com-plexité liée à l’héritage et accroît flexibilité et opérabilité ; mais elle est intrin-sèquement complexe car les grands groupes de fonctionnalités (applications) doivent laisser la place à un nombre accru de petits groupes de fonctionnali-té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’infras-tructures 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éga-tif sur le business case concerné. De plus, la courbe d’apprentissage des pre-miers 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

��

de l’effet de répétition. Il est donc essentiel d’appréhender les investisse-ments 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 porte-feuilles. Il en découle logiquement la nécessité de mise en place de procédu-res, 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 essen-tiel de garantir l’adoption proactive du concept de gouvernance SOA avant que cela ne devienne un problème comme avec la gouvernance informati-que.

Les deux figures ci-après montrent la différence entre une approche SOA avec gouvernance et une approche SOA sans gouvernance [Weblayers 2005b].

Figure 4.1 : SOA avec gouvernance

Déploiement

Politiques de développement Nouveaux processus métiers

Co

nfo

rmit

é

Initiative 1

Initiative 2

Initiative ...

ServiceGouvernanceInfrastructure SOA

AQ Déploiement Actions

Applications

Politiques d'action


��

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 architectu-raux » et font partie intégrante de l’architecture d’entreprise de la société.

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 archi-tecture d’un point de vue historique.

Figure 4.3 : Comment faire évoluer la complexité informatique

Développement

Aucune politique de développement

Au

cun

e co

nfo

rmit

é

Initiative 1

Initiative 2

Initiative ...

ServiceGouvernanceInfrastructure SOA

AQ Déploiement Actions

Nouveaux processus métiers

Aucune politique d'action

Applications

Système d’informationcentralisé physiquement

Système d’informationdécentralisé

physiquement

Système d’information découplé physiquement

mais intégré logiquement

- Compliqué, mais complexité maîtrisée

- 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

��

Au cours des années 1970 et 1980, les systèmes d’information étaient physi-quement 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 par-tie due à l’émergence de la technologie client/serveur. Cette évolution a fina-lement abouti à une complexité grandissante qui n’a pu être endiguée. Aujourd’hui, de nombreuses entreprises possèdent donc un système d’infor-mation 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 compo-sants physiquement séparés pourront fonctionner logiquement en interac-tion, 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 bruteDans 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 redondanteCette 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éuti-lisation 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.

•

•

•


��

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’architec-ture 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].

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’entre-prise est l’outil idéal pour garantir cette pertinence et cette cohérence.

Gouvernance d'entreprise

Offre de produits et servicesde l’entreprise SortieEntrée

Gouvernance

Gouvernance informatique

Produits et services informatiques

Figure 4.4 : Rapports entre gouvernance d’entreprise, gouvernance informatique et gouvernance SOA

�7

La Figure 4.4 illustre les rapports entre la gouvernance d’entreprise, gouver-nance 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 gou-vernance 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’appli-que également au niveau de l’entreprise. La Figure 4.5 illustre les sous-domai-nes de gouvernance influencés par l’introduction de la SOA.

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 fonc-tionne correctement, et qui a intégré des mécanismes pour la gestion des portefeuilles par exemple, ou pour les décisions d’investissements.

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- Investissement et financement- Souscription de contrats

Principaux domaines de gouvernance informatique- 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


��

SOA for Profit

Nous ne considérons pas la gouvernance SOA comme une forme de gouver-nance à 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’entre-prise 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 gou-vernance 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 servicesLa gestion de cycles de vie des servicesLe 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.

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’infrastructu-res. 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

•

•

•

Portefeuillesde

projets

Développement Actions

Portefeuilles d’applications/infrastructures

��

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, cel-les-ci nécessitent une gestion des licences comme des portefeuilles afin d’éviter les redondances. Ainsi, si l’on considère un portefeuille d’applica-tions, l’idéal est de ne voir figurer qu’une seule application par bloc de fonc-tionnalité.

Comme vous pouvez le constater sur la Figure 4.7, la SOA ajoute un compo-sant de gestion essentiel par rapport à la Figure 4.6 :

Figure 4.7 : Portefeuilles de gouvernance agrémentés du portefeuille de services

Une application est un ensemble spécifique de logiciels qui attribuent direc-tement certaines fonctionnalités d’un ordinateur à plusieurs tâches que l’uti-lisateur 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.

•

•

•

•

•

Portefeuillesde

projets

Portefeuillesde services/

applications/infrastructures



70

SOA for Profit

En fait, la gestion des services en portefeuille offre un avantage ; les porte-feuilles 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éres-sante. 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 gouver-nance SOA.

Figure 4.8 : Le portefeuille de services : la pièce maîtresse

Portefeuillesde projets

Portefeuillesde services

Portefeuillesd’applications/infrastructures


71

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’équipe-ments 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 pro-blè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 ceux-ci 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 revan-che, les services deviennent également problématiques car multi-utilisateurs. Dans ce cas également, tant qu’un service est utilisé, il ne peut pas être sup-primé.

La Figure 4.9 illustre le cycle de vie d’un service.

Figure 4.9 : Cycle de vie d’un service

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

État

Planifié

Spécifié

En cours de développement

Provisionné

Accepté sur plan opérationnel

Certifié

Publié

Opérationnel

Opérationnel

Retiré


72

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 plan opérationnel

Le service a été validé par le département responsable.

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.

7�

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.

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ération-nelles dans lesquelles les services sont assurés par le fournisseur. Les exi-gences non fonctionnelles, comme la disponibilité, la fiabilité et la scalabilité, en déterminent la qualité. Les limitations (comme le nombre maximum d’uti-lisateurs 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’utili-sation 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.

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


7�

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’architec-ture 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 Architec-ture) 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 cou-vrent 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’inter-médiaire de business cases. Les objectifs sont débattus au cours d’un dia-logue 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.

•

•

•

7�

Développement sans architecture – Choix délibéré dans certains cas, impli-quant peut-être des pressions extrêmes de délai, qui consiste à s’éloigner du cadre architectural.

Dans ce modèle, les services architecturaux (c’est-à-dire le développement et la maintenance de l’architecture) constituent clairement un processus de sup-port. 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 pen-dant 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-

•

Architectured'information

Architecturemétiers

Architecture technique

Dialoguestratégique

Servicesarchitecturaux

Développementsans

architecture

Développementavec

architecture

Solutions métier

Nouveauxdéveloppements

Solutions métier

Gouvernance

Architecture dynamique

ProcessusDYA

Figure 4.11 : Modèle de DYA


7�

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 tou-tes les opportunités de SOA et les exploiter dans les discussions sur les objec-tifs à 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 com-prendre qu’un « cycle d’adaptation » s’impose pour tout intégrer dans l’ar-chitecture à 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’architec-ture.

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.

•

•

•

•

77

Si une entreprise envisage de mettre en œuvre une SOA d’envergure à l’ins-tar d’une transformation stratégique, elle devra préalablement mener un dia-logue 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 devien-dra 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égi-que, 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 égale-ment utiliser des paramètres d’entrée (individu, informations, processus, réu-tilisation 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’entre-prise vis-à-vis de la SOA et par la méthode adoptée. Si une entreprise sou-haite commencer prudemment en n’utilisant que quelques services Web, inu-tile 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.


7�

SOA for Profit

4.7.3 Les différentes visions d’une architecture

Comment les différentes perspectives d’architecture d’entreprise s’apparen-tent-elles à la SOA ? Dans les services d’architecture, l’architecture est des-tiné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égiquesEn 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éve-loppements 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’entre-prise. 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 casesL’architecture destinée à assurer un soutien au niveau tactique pour des busi-ness 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 indis-pensable 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-

7�

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’intelli-gence 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’ar-chitecture de référence SOA d’IBM [IBM SOA Reference Architecture], il existe onze domaines distincts pour lesquels des choix s’imposent. [IBM 2005b].

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’architec-ture SOA. Sur la Figure 4.12, l’architecture de référence d’IBM est divisée en onze domai-nes, ce qui présente un certain nombre d’avantages majeurs. En effet, les entités peu-vent 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.

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 domai-nes du logiciel d’application.

Partenaire

Infrastructure

Optimisation et innovation métiers

Applicationmétiers

Accès

Interaction Processus Information

Ges

tion

des

serv

ices

info

rmat

ique

s

Dév

elop

pem

ent

ESB

Figure 4.12 : Architecture de référence SOA


�0

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’assem-blage 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.

InteractionCette 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étiersCette 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

�1

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 com-posants logiques modulables, flexibles et réutilisables.

InformationsCette 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 don-né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èsLa 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écifique-ment 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’entrepriseLe 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 fonctionna-lités présentes au sein du domaine applicatif.


�2

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étierCette 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 obte-nez ainsi de nouveaux paramètres d’entrée destinés à d’éventuels changements dans le processus de création d’activité.

DéveloppementCette 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 informatiquesDe 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.

InfrastructureDans ce modèle de référence, l’infrastructure est ce que nous appelons « tradition-nellement » l’infrastructure, à savoir les équipements, les systèmes d’exploitation, les

��

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 infor-mation. 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’in-frastructure 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 applica-tions. Les diverses ressources informatiques (serveurs et bases de données par exem-ple) 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 projetsEnfin, 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 pro-jets 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éve-lopper ou adapter. La PSA englobe aussi les contrats de niveau de service applicables au projet.


��

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 fina-lités et des groupes cibles divers.

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’infor-matique 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.

Dialoguestratégique

Servicesarchitecturaux

Développementavec

architecture

Nouveauxdéveloppements

Solutionsmétier

Pland'urbanisme

Architecturedomaine

Architecturedémarrageprojet

��

La SOA peut également jouer le rôle d’élément catalyseur pour la gouver-nance 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évelop-pement et à l’amélioration des concepts.

Que faire pour planifier la gouvernance ? Voici les trois domaines d’intérêt :Attribution des rôles et des responsabilités.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 gouver-nance SOA est de rester aussi simple que possible.

Rôles et responsabilitésL’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éter-miner 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 per-sonne ou un seul groupe de personnes pour valider la création d’un service.

RACI et RAEW : explicationLes 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.

1.2.�.

•

•

•

•

•

•

•

•


��

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 fonc-tions 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 gestionLes 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éci-sions 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éca-nisme de gestion de la gouvernance SOA. Cette autorité est en droit de refu-ser 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ôleDe 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 finance-ment. 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 finan-cements 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 gou-vernance 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 parti-cipants. Si aucun accord ne peut être conclu, le Conseil délègue les questions au comité de pilotage SOA.

�7

Comité de leadership informatique : assiste les pratiques de travail collaboratives entre plusieurs départements informatiques. Dans la SOA, il est essentiel d’encou-rager 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éveloppe-ment des services réutilisables, et non pas uniquement le développement de nou-veaux 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éutili-sables, 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 com-portement 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 appli-cations.


��

SOA for Profit

Tâches Fonction Respon-sable

Déci-deur

Consul-té

Informé

Identification Analyse globale du processus

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

Approvisionne-ment/Planification

Approvisionnement/Planification

Développement Développement des systèmes orientés services

Tenue du registre des services

Certification Certification


Publication Tenue du registre des services

Contrats Contact avec des entreprises (externes) utilisant les services


Retrait progressif Analyse des processus

Analyse des informations


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

��

StratégiesLes stratégies sont destinées à éviter une croissance non maîtrisée et à garan-tir des pratiques de travail efficaces (comme la réutilisation de solutions apportées à des problèmes récurrents). Elles restreignent la liberté de créa-tion 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 prin-cipes, 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 sou-mettent 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 mis-sion précise.

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 gouver-nance d’entreprise sans architecture d’entreprise aboutit certes à des méca-nismes 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.

Mécanismes Stratégies

Rôles et responsabilités


�0

SOA for Profit

Les structures organisationnelles de la gouvernanceL’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 SOACette é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 compo-sants, 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 combi-nant 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 SOACette équipe assure l’alignement des métiers et des services informatiques en appli-quant 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 informati-que 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 direc-teur 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 composantsIl 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érationsEnfin, 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-

�1

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 illus-trées à la Figure 4.15.

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.

Centred’excellence

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.

Prévoir un plan pour le portefeuille services des droits décisionnels. Définir les actifs et meilleures pratiques de création

organisationnelle.

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).

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

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

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é.

Proposer une entité unique détentrice du pouvoir décisionnel et communiquer les

meilleures pratiques, les actifs et lesmodèles SOA.

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.


�2

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éten-ces 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

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 compli-quent. Mais convient-il de mettre en place un concept de gouvernance lors-que 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.

Figure 4.16 : Niveaux de gouvernance SOA

Bonne préparation

Localement

Élev

éeBa

sse

Prêt

Au niveau de l’entreprise

Compétenceen matière degouvernance d’entreprise

Niveau de mise en œuvre de la SOA

Sensibilisation Très risqué

��

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 heur-ter à une forte prolifération de services, à une complexité accrue ou à un surcoût de gestion et de maintenance, sans pouvoir tenir la promesse princi-pale 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 enver-gure 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éan-moins, 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’entre-prise nécessite une certaine maturation. Faute de quoi, l’entreprise se trou-vera 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.


��

SOA for Profit

Mécanismes de gouvernanceDans 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 serviceLe 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’orga-nisation 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 pro-cessus 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 marchandisesSans 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

•

•

•

•

•

•

��

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 projetsDans 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 four-nisseur. 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 bud-get du fournisseur est issu du budget spécial consacré aux services de marchandi-ses.

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 impor-tant 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éuti-lisation 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’ef-fectuer de manière cohérente et logique.

Les principaux domaines de la gouvernance SOA sont la gestion des porte-feuilles de services, la gestion des cycles de vie des services et le registre des


��

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 gouver-nance d’entreprise. Il incombe à l’architecte d’entreprise de dépasser les limi-tes 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.

�7

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 par-tage des services au sein de l’entreprise dans lequel la localisation des servi-ces importe peu tant que le niveau de service fourni est conforme aux atten-tes. 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 envi-sager 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 iden-tifier 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 long-temps 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 humai-nes, l’impression ou les communications. Comme avec les autres modes d’op-timisation, 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’ar-chitecture 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.

��

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 cou-vrant 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’in-novation dans la branche d’activité et au développement de solutions infor-matiques.

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’entre-prise 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 confi-guration des blocs peut varier suivant les processus et les produits ; mais les éléments de base restent identiques. Ici, nous observons une grande simili-tude 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 change-ments.

��

Pour trouver les business models adaptés à votre entreprise, vous devez étu-dier 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 natureDans 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. Natu-rellement, les modèles sont aisément adaptables à votre secteur d’activité, que vous travailliez dans la finance, la santé ou toute autre industrie.

Retour clientsAu 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 for-tement 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 effective-ment 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 (1865-1918), 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-


100

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.

Direction Personnel

DivisionPersonnel Personnel Personnel

Unité

Unité

Unité Unité

Division

Unité

Division

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 centrali-sé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 organi-sationnelles. 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 servicesCe 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 solu-tions, 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.

101

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.

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 produc-tion, mais également pour décider où stocker les marchandises dans l’en-trepô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échis-sons à une organisation, sont les domaines métiers, les potentiels (« toutes les

Créer activités

Traiter commandes

Ventes Production Logistique FinancePlanifier

productionProduire plastique

Traiter plastique

Distribuer produits

Gérer entrepôts

Fournir services

Assurer paiement

Processus

Domaines

Capacités

Services métiers

Enregistrer prospect

Enregistrer commande

Afficher stock

Recevoir paramètres

Recevoir paramètres

Stocker marchandise

Transport marchandise

Charger marchandise

Envoyer facture

Attribuer capacités

Optimiser production

Actualiser plan

Contrôler processus

Contrôler processus

Envoyer marchandise

Préparer chargement

Décharger marchandise

Confirmer envoi

Contrôler APL


102

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étierLa 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’acti-vité. 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 acti-vité et des services informatiques en place. La Figure 5.3 illustre une division simple mais courante en domaines.

Approvision-nement Production

Planification et exécution

livraison

GRCet ventes

Management de la qualité

Planificationprincipale

Finance, comptabilité et

contrôle de gestion

Gestiond’entrepôts

Développementde produits

Planification et analyse

des marchés

Figure 5.3 : Cartographie du domaine métiers

Cartographie des potentielsDe manière générale, les domaines sont une structure de classement norma-lement rattachée à la fonction organisationnelle chargée des services métiers, le « QUI ». Pour obtenir une vue davantage orientée action, nous devons pas-ser à la cartographie des potentiels, le « QUOI de haut niveau ».

10�

Figure 5.4 : Cartographie des potentiels (à un stade anticipé dans la réalité)

Cartographie des processus ou unitésL’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 des entrepôts

Planification et exécution livraison

Gestion de la relation client

et venteProduction

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 celui de la Figure 5.6.

Créer activité

Monitor Delivery process

Control Strategic KPI:s

Planifier production

Fabriquer plastique

Traiter plastique

Gérer entrepôts

Distribuer produits

Traiter commande

Figure 5.6 : Contexte des processus basé sur les potentiels


Maintenance installations

Planification production

Gestionde la

relation client

Gestioncommandes commerciales

AchatsFabricationplastique

Planificationlivraisons

Ventes

ComptabilitéTraitement plastique

Distribution produits

Développement marché

Développement produits

Consolidation financière

Gestion des entrepôts

Planification logistique

Facturation

Managementde la

qualité

Management environnemental

Contrôlede gestioncorporate

10�

SOA for Profit

Business model d’une ligne de servicesVous 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 plu-part 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 ser-vices.

Créer activité

Suivre le processus de fourniture

Suivre les KPI stratégiques


Fabriquer plastique

Traiter plastique

Gérer entrepôts

Gérer entrepôts

Distribuer produits

Terminer fourniture

Traiter commande

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é confor-mément à un contrat de niveau de service (SLA) spécifique ». Dans le proces-sus 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 :

La souscription du contrat de services s’effectue au niveau du bloc Créer activité.Les commandes sont réceptionnées et gérées dans le bloc Traiter com-mandes.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 for-mage 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.Les pots sont livrés de l’entrepôt à l’imprimeur du client sur demande, conformément au SLA.

1.

2.

�.

�.

�.

�.

7.

10�

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 busi-ness model dynamique et les cartographies que nous pouvons créer. Comment identifier les éléments spécifiques aux modèles de votre entreprise et êtes-vous à 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’en-treprise 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 valeurprocessus associésstratégie en cascade

�.

�.

•

•

•


10�

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 lar-gement 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 struc-turé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 pour-rez é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 valeurLa 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.

Commercialiser l'intelligence

Développer produit

Ventes Production DistributionLivraison

proche

Alignement de planification, contrôle et stratégie d'activité

Gestion de l'activité & Suivi de stratégie

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.

107

Développer produits Ventes

Gestion de l'activité

Fonctions support

Production DistributionPlani-fication

et dévelop-pement métier

Marché

Fourniturede services

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 pro-duits basés « services ». Une telle approche aboutit généralement à une solu-tion 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.


10�

SOA for Profit

Commercialiser l'intelligence

Développer le produit

Ventes Production Distribution Fourniture proche

Alignement de planification, contrôle et stratégie d'activité

Gestion d'activité & Suivi de stratégie

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 cartogra-phie des potentiels.

Élaborer une stratégie en cascadePour analyser l’entreprise, une autre approche constructive consiste à consi-dérer la stratégie métiers comme l’élément clé. Vous pourrez ensuite déter-miner comment mettre en œuvre la stratégie dans ce contexte. Quelles mesu-res doivent prendre les unités pour appliquer la stratégie ? Comment les activités combinées soutiennent-elles la stratégie ? Cela vous aidera à iden-tifier 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 potentielsAprè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éli-sation SOA ou plus précisément la cartographie des potentiels.

10�

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

Com

man

de Encais-sem

ent

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.

ServicesDans ce processus de création d’une base SOA, l’étape ultime consiste à par-courir 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.


Gérer installation


Traiter commandes

Gérerla relation

clientGérer la qualité

Fabriquer plastique

Souscrire contrat

Gérer les problèmes en-

vironnementaux

Achetermatières premières

Planifier les

livraisons

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

Gérerlivres de comptes

110

SOA for Profit

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 sor-tants pour chaque service métier. Si vous manquez de temps, vous vous contenterez des services les plus importants.

Un monde de servicesLorsque 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 (servi-ces 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.

Achat matières premières Gérer entrepôts

Gérer la relation client et créer activité

Planifieret exécuter livraison

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

Servicemétier

111

Une autre méthode de transformation métier stratégique : le Concept Com-ponent Business Modelling (CBM) d’IBMLe 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.

Stratégie service clientèle

Planification marchandises

Planification canaux

Planification assortiments

Planification espace

Planification promotion

Développement produits

Approvisionnements

Produits/Services

Clients Canaux

Compétences

Niv

eau

de

resp

on

sab

ilité

Logistique Gestion d'entreprise

Gestion trésorerie et risques

Contrôle d'inventaire

Encaissements et banque

Conformité juridique et réglementaire

Stratégie d'entreprise

Planification d'entreprise

Planification financière

Planification financière

Création réseaux

Création entrepôts

Planification flux de demandes

Niveau de responsabilité

Direction

Contrôle

Exécution

Stratégie marketing

Routage entrant Gestion performance d'entreprise

Planification réceptions

Planification livraisons

Planifications transporteurs

Gestion campagne

Gestion services

Service clients

Marketing

Publicité

Relations publiques

Source : IBM Business Consulting Services Composant clé

Communication clients

Stratégie canaux

Constitution stock

Stratégie pour les biens immobiliers

Création Internet

Création catalogue/centre d'appels

Flux produits

Gestion articles

Gestion produit

Gestion PO

Gestion fournisseurs

Réapprovisionnement

Gestion recettes/douanes

Gestion canaux

Programmation

Affectation

Gestion inventaire/OTE

Prévisions demandes

Gestion prix

Gestion contenu

Gestion fournisseur

Gestion travail

Gestion commandes

Construction d'immeubles

et gestion d'installations

Prévention pertes

Gestion commandes

Approvisionnement indirect

Gestion RH

Gestion inventaire

Gestion flotte

Logistique inverse

Gestion marchandises

Gestion prix/signatures

Gestion entrepôts Comptabilité et suivi financiers

Gestion transport

Système et opérations informatique

Figure 5.14 : Cartographie métiers composants

Pour définir chaque composant, vous devez attribuer cinq dimensions, comme le montre la Figure 5.15.


112

SOA for Profit

Gérer

Diriger

Contrôler

Exécuter

Dimensions d'un composant métier

Objetif métierPourquoi existe-t-il ?

Services Éléments adoptés et proposés à d'autres composants ?

ActivitésMesures cohésives et

simples prises régulièrement ?

RessourcesActifs corporels et

ressources humaines nécessaires ?

GouvernanceModes de gestion des activités ressources ?

Concevoir Acheter Faire Vendre

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 effec-tuer 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’entre-prise 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-

•

•

•

•

11�

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

Reporting groupe

Management de la qualité

Processus fédéraux

Professionnel Détail Externe Interne

Gestion ventes & commandes

Prévisions et planification centrale

Figure 5.16 : Cartographie des potentiels fédéraux

Au niveau de l’unité, deux standards coïncident : le standard global et le stan-dard 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

Standard local

Gérer installation


Fabriquer plastique

Gérer entrepôts


Acheter mat. premières

Traiter plastique

Gérerla qualité

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.


Du modèle au logicielPrenons 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.

Entrée marchand.

Transfert marchandises

Gestion d'entrepôts

Chargement routier Chargement ferroviaire

Condi-tionnement

marchandises

Trans-bordement

Inventaire stocks

Interface physique marchan-dises

Indiquermarchand.

reçues

Interface d'intégration

Recevoir conseils

Indiquertransfert march.

Indiquerstocks

Recevoir instructions

Réparation Sortie marchandises

Gestion palettes

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 techni-ques 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 propo-ser 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 :

SOA for Profit

11�

11�

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 valeurTrouver 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.

Créeractivité

Sécuriser paiement

Facilité de mise en oeuvre

Avantages métier

Distribuer produits



Planifier capa-cité logistique

Traiter bon de commande

Figure 5.19 : Matrice Gain/Facilité

•

•

•

•

•

•


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 dif-ficulté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 prioritairesIl 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’en-tretiens. 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 poten-tiels 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

Gérer la relation

client

Traiter bons de

commande

Gérer la qualité

Fabriquer plastique

Planifier livraisons

Créer activité

Gérer problè-mes environ-nementaux

Achetermatières premières


Traiter plastique

DistributeProducts

Analyser marché


Contrôler KPI

d’entreprise

Besoin de changement

Consolider finance

Gérer entrepôts

Planifier logistique

Sécuriser encaissements

Besoin de changement Besoin de changement élevé

Figure 5.20 : Cartographie des potentiels avec priorités de changement signalées par des couleurs

SOA for Profit

11�

117

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 valeursMalgré sa simplicité, la chaîne des valeurs est une plate-forme assez intéres-sante 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.

Vente Consom-mateur

Developper nouveaux produits

MétiersPlanification Processus de gestion métiers (y compris management de la qualité)

Marketing

Zone critique

Planifier demande Ventes Production

Gestion des

stocksDistribution

Opportunité à court terme 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 cascadePour 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-


11�

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 SOACet exemple est un mini-projet que vous allez élaborer pour établir un plan de trans-formation 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étho-dologie 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 obtien-drez :

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 :Entretiens ciblésAnalyse et préparations d’atelierAtelierDocumentation et suivi.

•

•

•

•

•

1�2�3�4�

11�

1. Entretiens ciblésLes entretiens ciblés donnent un aperçu précis de la stratégie, des plans et des atten-tes d’un groupe d’acteurs clé. Ils sont menés individuellement avec tous les partici-pants. Dans chaque cas, vous utiliserez un modèle d’entretien bien préparé. La bat-terie 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 per-sonnes. 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 chan-gement.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 vous-mê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é.

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•


120

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’atelierLe 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’opportu-nité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 brains-torming, à établir des priorités et à identifier les éventuelles interférences à l’avance.

3. L’atelierL’atelier amorce les communications, établit un consensus et donne un aperçu com-mun 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ésenta-tion).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 (brains-torming structuré).S’il reste encore du temps : définition d’un plan d’action (discussion).

•

•

•

•

•

•

•

•

•

121

4. Documentation et suiviPour 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 serait-ce 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 pro-cessus ? 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 exploita-bles 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


122

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 servi-ces 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 davan-tage 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’or-ganisation fonctionnelle avec son architecture orientée silos jusqu’à une architecture orientée services. La transformation est le résultat final du pro-cessus de refonte d’une activité.

Pour terminer, nous vous avons donné quelques outils pratiques pour démar-rer la discussion et définir les priorités de changement.

12�

6 Une entreprise orientée services

6.1 Introduction

Dans le chapitre intitulé « Repenser votre activité », nous avons expliqué com-ment les entreprises traditionnellement organisées en lignes de métiers se trou-vaient 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 prin-cipes 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 informa-tions qui suivent vous aideront à repenser votre activité et à anticiper les changements qui interviendront lorsque la SOA sera devenue le modèle d’ar-chitecture 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 ache-teurs de téléphones portables. Sur cette base, vous avez défini une infrastruc-ture 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.

12�

SOA for Profit

Votre entreprise s’est structurée avec les entités requises, chaque entité pos-sédant son propre département informatique chargé de concevoir les meilleu-res 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éalisa-tion de tâches spécifiques (facturation, entrée des factures clients ou opéra-tions 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 nou-velles offres et rester compétitif, vous étudiez votre structure et découvrez que toutes ces nouvelles offres vous obligent à repenser vos solutions infor-matiques. 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 nouvel-les 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. Jus-qu’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édiate-ment, 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-

12�

vaut à responsabiliser l’individu et à proposer des règles de base pour l’utili-sation 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’entrepriseIl 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’infor-matique.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 limi-tes 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

•

•

•

•

•

•

•


12�

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 ins-tantané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 exi-gences 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 tradition-nelle et décomposer les structures organisationnelles existantes (en les com-binant 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 collabo-ration, 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, Collabora-tion 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’indivi-dus et non de services programmés. Dans une entreprise, les employés, par-tenaires 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

127

des flux de travail destinés à soutenir les activités communes et la coordina-tion 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 dispo-sent d’outils spécifiques de planification et de conception afin d’identifier, orchestrer et chorégraphier les services de niche depuis les strates inférieu-res. Des tableaux de bord exécutables et des outils d’information configura-bles fournissent en temps utile des clichés instantanés de paramètres métri-ques sur des flux de services et des données de productivité.

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ère-plan 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 com-munication 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

Servicesd'équipe

Orchestration,Création et

Suivi des services

Outils d'équipe

Empl

oyés

C

lient

s /

Part

enai

res

Outils externes pour clients

et partenariats

Services départementaux

Services entité

Services humains organisationnels

Bus d'orchestration et de collaboration (COB)

ODOE et lieu de travail à la demande

Services division

Services groupe

Outil répertoire de services

Outil répertoire d'actifs

Outil répertoire d'employés

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 classe-ments en répertoires destinés à identifier les individus, les actifs et les servi-ces 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’orches-tration des services et de suivi reposent sur des outils appropriés qui aident la direction à mettre en place les services identifiés et disponibles. Finale-ment, le résultat sera la fourniture du service demandé au client.


12�

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 indubita-blement 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 départementaux 1

Services d’équipe 1

Services d’équipe 2

Services d’équipe N

Services d’entité 1

Services de division 1

Services de groupe 1

Services départementaux

N

Services d’entité

N

Services de division

N

Services de groupe

N

Centrés sur la mission

et les objectifs

Centrés sur la

stratégie

Centrés sur la mission

tactique

Centrés sur la définitiondes objectifs

Orientés tâches

et activités

Figure 6.2 : Bus de services humains partie intégrante du réseau opérationnel

12�

La Figure 6.2 illustre les différentes strates de services d’un HSB et leur rai-son 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égra-phie des services. Leurs rôles et leurs responsabilités varient en fonction de la strate et restent essentiels pour le HSB.

Services d’équipeCe 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épartementauxLes services d’équipe sont regroupés au niveau départemental pour la réalisa-tion des objectifs clés de l’entreprise. Le but est de créer des services départe-mentaux comme le « test du composant A dans le produit XYZ », le « bench-marking 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’entre-prise 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 rationa-lisé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 fon-damentales. Il faut des talents d’encadrement pour concevoir ces services char-gés d’exécuter et de proposer les éléments tactiques et de gérer les résultats


1�0

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’étrangle-ment des processus, reformule les caractéristiques des services si nécessaire, élimine les redondances et définit de nouveaux services « émergents ».

Services de divisionLes 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 groupeCes services sont entièrement dédiés à la conduite de la mission et des objec-tifs 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

1�1

preuve d’une grande réactivité face aux nouvelles opportunités et aux mena-ces de la concurrence. Les services basés sur l’informatique et sur les indivi-dus à 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 flexi-bilité.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.

•

•

•

•

•

•

•

•


1�2

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 utilisateur

Portails de consultation de services ou produits

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 techno-logies 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éfi-nition 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

1��

validation formelle réduira à néant les avantages. Par ailleurs, les collabora-teurs 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 organisation-nelles. Vous verrez ainsi comment les services combinés à certains outils tech-nologiques de communication peuvent aboutir à une méthode de travail radi-calement 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.


1��

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’ac-tivité et la gestion des changements, vous pouvez utiliser certains éléments organisationnels et opérationnels pour obtenir les résultats escomptés. Néan-moins, 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’adap-tation d’une architecture orientée services nécessite des collaborateurs orien-té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 ser-vices 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 doi-vent 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.

1��

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 gou-vernance 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éus-site 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 contri-bution dans la valeur de l’entreprise en général, ainsi que dans des cas d’ac-tivité 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 puis-sent 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 mar-ché 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’environ-nement 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éu-tilisation 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

1�7

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’entre-prise, 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’en-treprise 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 stan-dards, 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).


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’im-pose 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’établis-sement 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.

Accélérer mise sur le marché

Augmenter recettes

Aligner objectifs métiers et informatique

Architecture d'entreprise

Conformité de l'activité

Objectifsmétiers

Fonction (définition services)

Sécurité et conformité SI

Performance et qualité (KPI)

GouvernanceArchitecture de référence

Feuille de route

Objectifs SI

SOA for Profit

1��

1��

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 éga-lement une multitude de rôles particuliers décrits dans les sections suivan-tes.

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étiersLe 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 responsa-bles informatiques identifiés (architecte d’entreprise, BSC et autres profes-sionnels 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


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 trou-ver 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’archi-tecture 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 servicesLe 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éu-tilisation 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 éga-lement à 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 redon-dants, le responsable demande aux équipes de projet de parcourir le référen-tiel 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 architectu-res 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 éga-lement à 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 ser-vices dans le référentiel.

SOA for Profit

1�0

1�1

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’entre-prise 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 quel-ques 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’entrepriseL’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 servicesLe 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.


1�2

SOA for Profit

L’administrateur système et base de donnéesCe responsable assure l’installation et la maintenance continue de l’infras-tructure technique : matériel, systèmes d’exploitation, bases de données et middleware. Certains aspects de l’intégration des informations sous SOA don-nent 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 servicesLe 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 servicesLe 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’outilsLe 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éces-saires 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 judi-cieux 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éve-loppeurs et des consommateurs. Cette personne peut même devenir un conseiller, notamment par rapport à Web 2.0, les utilisateurs étant générale-ment amenés à modifier leur espace de travail en fonction de leurs tâches quotidiennes.

L’animateur des transferts de compétencesCe rôle donne accès à des experts du domaine et à des instructeurs techni-ques 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-

1��

lement être assuré par des « customer proxies », qui représentent des deman-des de services individuelles dans la SOA. Une fonction caractéristique de cet animateur est d’apporter une assistance au responsable du registre des ser-vices. Ce rôle peut également faire partie intégrante du travail du responsable du registre, suivant la taille des équipes.

Le responsable projet SOACe 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 servi-ces).

L’administrateur système SOAOutre la gestion et la surveillance de l’infrastructure de plate-forme, l’admi-nistrateur 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 regis-tre de services évoqué ci-dessus. Néanmoins, l’administrateur système SOA occupe un poste administratif, non proactif.

Le concepteur de flux de processusLe 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 par-ticuliers. 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’automa-tisation 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 changean-tes.


1��

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 registreL’administrateur registre détermine le mode de personnalisation et de peu-plement 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 éven-tuelle 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’admi-nistrateur 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’entre-prise 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 pro-fessionnel 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 respon-sabilité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 produc-tion industrielle s’est largement automatisée, nous nous trouvons confrontés à

1��

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’indus-trie 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 cho-ré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 nom-bre grandissant de services ont été automatisés pour faciliter le travail de cer-taines entités : la force de vente qui dispose directement sur le terrain d’infor-mations concernant les clients et leur situation financière, les experts comptables spécialisés en fiscalité qui accèdent à des règles (rapidement obso-lè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 fonc-tion 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’in-terface 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 impli-qué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.


1��

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 individuel-lement, 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 mana-gers 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 « res-ponsabiliser » 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 nou-veaux 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 four-nit une vue d’ensemble relativement juste des aptitudes cognitives des colla-borateurs. Mais pour obtenir les meilleurs résultats dans une économie orien-té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 mon-tre 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 possi-bles d’une équipe en combinant suivant un certain dosage les talents, les

1�7

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 entre-prise, 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 contri-bution 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.


1��

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éussis-sez 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’enga-gement 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 regis-tres 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 sou-haitant 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’entre-prise. 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.

1��

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 davan-tage à 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 stra-té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’in-vestissements conséquents.

D’autre part, reléguer la SOA au rang d’un domaine d’application de peu d’en-vergure et au gain potentiel limité, sans prendre de risque, ne fera que renfor-cer 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’ob-tenir 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. Tou-tefois, cette solution ne correspond pas entièrement à l’ensemble des domai-nes visés, étant donné qu’elle est axée uniquement sur des problèmes infor-matiques 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 indis-pensables d’une telle approche. Mais avant toute chose, une vision claire de

1�0

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 entre-prise 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 aux-quels 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 mul-tidimensionnelle de la SOA.

Description du modèle de maturité SOALe 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 SOALe modèle identifie 20 secteurs différents requérant une attention particu-liè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.

•

1�1

La technologie est la deuxième catégorie axée sur la façon dont les sys-tè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 connais-sance 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

Technologie 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

Personnel 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

Tableau 8.1 : Vingt secteurs clés de la maturité SOA

Niveaux de maturité SOAAfin 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-

•

•


1�2

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’orga-nisation. 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é SOAAfin de déterminer les niveaux, le modèle de maturité SOA s’appuie sur un instrument de mesure objectif. Les exigences pour chaque niveau apparais-sent 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 main-tenant détailler brièvement ces secteurs.

1. Engagement et motivationL’engagement et la motivation des parties prenantes de la SOA sont primor-diaux 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 : direc-teurs 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, recon-naissant 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 organisation-nels.

1��

2. Relation avec les projetsLa 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 tire-ront 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ésExpliquer 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’architectureLe 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 pro-cessus continu de facilitation. Plus le processus de développement de l’ar-chitecture 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’en-treprise.

5. Utilisation de l’architectureLe 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 pro-jets individuels, ou en tant qu’instrument de gestion pour l’entreprise toute entière.


1��

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’architec-ture, 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égra-tion 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 servicesLa 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’ap-plication 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’avan-tages 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 SILes 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’im-proviser 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’infor-mation, 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’informationL’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

1��

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 planificationLa 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’optimi-sation continue de processus de planification et de contrôle.

12. Technologie et standardsLa 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écomposi-tion. Cette réutilisation par décomposition ne constitue pas une évolution spontanée. Certains résultats peuvent être atteints en capitalisant d’un pro-jet à l’autre. En revanche, la valeur réelle est obtenue en assurant la concep-tion, la planification, la gestion et, plus difficile mais plus efficace, le finan-cement.

14. Mise en œuvre de processus métiers dans le système d’informationLa 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 ren-dement 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 plate-forme sur laquelle fonctionne un composant.


1��

SOA for Profit

16. Sécurité de l’informationLa 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’in-frastructure 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 informatiqueDans un environnement SOA, les professionnels de l’informatique concernés doivent disposer des compétences requises. La SOA a une influence impor-tante sur les professionnels de l’informatique suivants : architectes informa-tiques, analystes informatiques, concepteurs, ingénieurs en logiciels, ingé-nieurs d’infrastructure, testeurs et ingénieurs de maintenance.

18. Compétences SOA du personnel métiersDans 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’en-treprises, concepteurs de processus, testeurs et employés de maintenance fonctionnelle.

19. Connaissance et état d’esprit SOA du personnel informatiqueL’orientation services n’est pas seulement un style architectural, c’est égale-ment une façon de penser en termes de services et de réutilisation de ces ser-vices, 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étiersL’orientation services n’est pas seulement un style architectural, c’est égale-ment 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éutili-sables 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.

1�7

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 fac-teurs 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’engage-ment et la motivation, la vision de l’architecture, la technologie et les stan-dards, 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évelop-pement 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 matu-rité, 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 carac-tè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évelop-pement 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évelop-pement, 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 effor-cer 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.


1��

SOA for Profit

Secteur clé Niveau A Niveau B Niveau C Niveau D

1 Engagement et motivation

Budget et temps disponibles pour les initiatives SOA

L’approche SOA est soutenue par le management de l’entreprise

L’approche SOA est intégrée dans le processus de l’entreprise

2 Relation avec les projets

Architecture pour diffuser la communication

Le processus architectural prend en compte les retours d’informations des projets

Les architectes, commerciaux et informaticiens établissent ensemble l’architecture du projet

Dialogue continu entre les architectes, commerciaux et informaticiens

3 Rôles et responsabilités

Service 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


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


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é


Les durées de vie des services dépendent de celles des applications qui les livrent

Contrats de niveau de services

Durée de vie prévue (y compris retrait)

Financement de l’utilisation des services (marché des services)

1��


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 commer-cialement)

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


Besoin de justifier formellement un retour sur investissement direct pour chaque projet métier SOA impacté

Projet SOA spécifique

Générique entreprise

Optimisation continue du processus de budgétisation et de planification

12 Technologie et standards

Technologie ad hoc choisie en cas de besoin

Référentiel basé sur une informatique définie et prouvée

Stratégie motivée

Anticipation des changements technologiques et adoption des nouveaux standards

13 Décomposition et réutilisation

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 in-formatique sont subdivisés et la réutilisation est répandue.

14 Mise en œuvre des processus métiers dans le système d’information

Services métiers existants au sein de silos

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


1�0

SOA for Profit


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 per-sonnel métiers

Basiques Modérées Développées


Sensibilisation partielle

Sensibilisation au niveau de l’entreprise

État d’esprit SOA normal


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.

1�1

Engagement et motivationLes 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 planificationLa 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’informationPour l’instant, faisons profil bas. Les relations entre les services métiers et informati-que 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 applica-tions sans devoir gérer les connexions.


1�2

SOA for Profit

Sécurité de l’informationL’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’entre-prise. Malheureusement, comme certains directeurs des opérations informatiques vous le diront, les projets refusent le plus souvent d’utiliser des standards architectu-raux 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 mar-chent pas.

Rôles et responsabilitésLe 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’architecturePar 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’architecturePar 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.

1��

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 SOAEn 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éutilisationIl 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’adap-tation 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 servicesSon é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 sec-teurs 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


1��

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 appa-raî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 ver-tical 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.

Secteur clé

Stade

0 1 2 3 4 5 6 7 8 9 10 11 12 13

1 Engagement et motivation A B C

2 Relations avec les projets A B C D

3 Rôles et responsabilités A B C


A B C

5 Utilisation de l’architecture A B C


A B C

7 Gestion de la qualité A B C D


A B C D

9 Vision de l’architecture A B C D


A B C D


A B C D

12 Technologie et standards A B C D

13 Subdivision et réutilisation A B C D


A B C D

1��


A B C D

16 Sécurité de l’information A B C D


A B C


A B C


A B C


A B C

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 gra-phiquement 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 judi-cieux 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


1��

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 sec-teurs de structure et de gestion.

1�7

Toutefois, il faut passer par une étape préalable consistant à fixer des objec-tifs 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.

Secteur clé

Stade

0 1 2 3 4 5 6 7 8 9 10 11 12 13





A B C



A B C


8 Gestion du portefeuille de services A B C D


10 Alignement métiers du système d’information

A B C D

11 Budgétisation et planification A B C D




A B C D


A B C D



A B C


A B C


A B C


A B C

Tableau 8.5 : Modèle de maturité SOA pour un exemple d’entreprise au stade 0


1��

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 fonc-tionnement actuel. Remplissez le modèle décrivant la situation actuelle. Les aspects comptabili-sant 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 met-tez-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 nom-breux à 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 à cha-que niveau. En utilisant ces points de contrôle, il est possible de déterminer

•

•

•

1��

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 bous-sole 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, cer-tains 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.


170

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 éga-lement asseoir une crédibilité en offrant, dans les meilleurs délais, des résul-tats 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.

171

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 expli-quer 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ère-t-il d’un autre projet ?

Dans le présent chapitre, nous allons tout d’abord présenter une méthode glo-bale 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. Autre-ment 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 objec-tif de finalisation du projet, mais plutôt par le souhait de concrétiser les objec-tifs 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’instau-rer 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-

172

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’en-treprise 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’éta-blissement de la feuille de route en est un composant.

Stratégie d’entreprise,

Objectifs à long terme

Visionmétiers

SOA

MaturitéSOA

Feuille de route

SOA

Projet métier

Projet capacitaire Projet capacitaire

Projet métier

Projet métier

Points d’entrée

Projet

Projet métier

Projet métier

Projet métier

SI générique / SOA

Technologie

Processus

Personnel

Situation actuelle

Objectifs métiersGoulets

d'étrangle-ment,

OpportunitésPoints

d’entrée

Que

sou

haite

z-vo

us r

éalis

er ?

Où

en ê

tes-

vous

mai

nten

ant ?

Que

lles

mes

ures

dev

ez-v

ous

pren

dre

et à

que

l mom

ent ?

Projet capacitaire

Planning de mise en œuvre de la SOA

Stratégie Analyse Plan Introduction Développement Action

Projet capacitaire

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 : Pro-cessus, Technologie et Personnel.

•

•

17�

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 baseAvant d’établir une feuille de route SOA, vous devez choisir un certain nom-bre 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 men-tionné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 portefeuille de service (et donc la durée de vie des services) ?

Entreprise - Si l’entreprise est propriétaire des services, il est logique que le portefeuille soit également piloté à ce niveau.

- Les services sont des composants automatisés de la fonctionnalité de l’entreprise dont le service informatique est souvent le seul à savoir qui utilise quoi et qui peut avoir une vue globale des domaines.

Service informatique

- 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

•

•

•

•

•


17�

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

- Nécessite une bonne distinction entre les domaines d’activité

- Risque de recouvrement

Organe central

- Un endroit centralisé où tous les contrats de services sont gérés.

Qui gère le portefeuille de services en termes d’exécution ?

Propriétaires du domaine

- Le propriétaire du domaine se sent responsable de la fourniture du service

- Les propriétaires de domaine doivent réglementer la gestion de la surveillance pour eux-mêmes

Organe central

- Un lieu centralisé où la fourniture de tous les services est surveillée

Qui est le propriétaire d’un service à fournir ?

Entreprise - L’entreprise demande et définit les fonctionnalités en termes de services que d’autres composants doivent fournir. Il 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.

- Nécessite une division nette de l’entreprise en domaines et l’affectation des services

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.

Le choix des domaines

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

17�

Comment les services sont-ils financés ?

Par les projets

- 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 central

- Suscite une motivation pour arriver à des services réutilisables

- Plus de chance de succès pour les initiatives SOA

- Réglementation requise- Financement inapproprié du budget central

Comment l’utilisation des services est-elle calculée et mise en place ?

Suivant usage

- Juste répartition de la charge - Réglementation requise

Pas du tout - Pas d’administration pour le re-calcul des coûts

Tableau 9.1 : Choix de base de la mise en œuvre de la SOA

Le choix des projets métiersLa mise en œuvre de la SOA s’effectue principalement dans le cadre de pro-jets 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 ajou-té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 comman-des.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écom-pense. 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.

•

•

•

•


17�

SOA for Profit

Il faut maintenir les risques à un niveau assez bas pour optimiser les probabi-lité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. Naturel-lement, 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.

Valeur métier

Source : Gartner (août 2006)

Complexité informatique Sweet Spot

Démonstrationtechnique

convaincante

Risque élevé,valeur ajoutée

importante

C'est un début

Anecdotique Visionnaire

Réussite technique Leadership

Démontre la vision

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

177

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éres-sera plus ses sponsors et sera considéré comme anecdotique, sans valeur.

Comment la SOA évite-t-elle la fraude dans les restaurantsUn 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 éta-blissements. 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 impor-tante.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 bottom-up).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).

•

•

•

•


17�

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 capacitairesComme 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 gouver-nance 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 domai-nes 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’exem-ple 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

•

•

•

•

•

•

•

•

•

•

17�

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 capa-citaires. 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éutilisa-tion et Connectivité) donne une réponse à la question sur les domaines possi-bles 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 pro-jet SOA. Quel est le problème métier à résoudre en introduisant la SOA ?

En partenariat avec Mercer Management Consulting, IBM a étudié les prati-ques é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.


1�0

SOA for Profit

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 cha-que projet apporte une réelle valeur métier. De cette manière, chaque entre-prise sera prête à optimiser les bénéfices d’une SOA, à comprendre les avan-tages 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éutili-sation.

Dans les sections qui suivent, nous allons dresser de brefs descriptifs et don-ner 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 indi-quera la démarche à suivre.

Connectivité

Réutilisation

Utilisateurs

Information

Processus

1�1

9.3.1 Collaboration centrée sur les utilisateurs

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éliora-tion 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, sou-haitent améliorer leur productivité en donnant à leurs employés, à leurs clients et à leurs partenaires la possibilité de créer un environnement per-sonnalisé pour agir en interaction avec d’autres personnes et informations dans le contexte des processus métiers. Cette approche conduit à des interac-tions entre individus et processus avec des niveaux de service cohérents.

Par où commencer ? Tout d’abord, prenez les projets pilotes ciblés qui don-nent 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.

Connectivité Réutilisation

Information Processus

Utilisateurs


1�2

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’informationInstaurer et améliorer la collaboration à l’intérieur et à l’extérieur de l’entrepriseRéduire les délais de mise sur le marché, déployer de nouveaux servicesAmé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

IntroductionIl 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 établisse-ments militaires).Une étroite collaboration entre ces organisations, l’accès aux informations, les sour-ces 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épar-ties 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.

•

•

•

•

•

1��

Les enjeux métiersLe 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’optimi-ser 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éfi-ciences conformément à la législation publique en vigueur pour les établissements scolaires financés par des fonds publics. Sans les rapports exhaustifs de ces établis-sements, les financements sont en danger. Le but était aussi d’améliorer l’alignement entre les processus métiers et l’environ-nement informatique à partir des actifs existants, reliés autant que possible par des standards ouverts, indépendants des solutions propriétaires.

La solutionAprè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 applica-tions, 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’environ-nement peut se décliner en plusieurs langues pour améliorer la communica-tion.Certaines des applications disparates ont été intégrées après une certaine subdivi-sion (« componentization ») en utilisant des services web, en préservant les actifs existants et en évitant tout blocage par des solutions propriétaires.


1��

SOA for Profit

Les avantagesLes 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ésor-mais 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.

9.3.2 La gestion des processus métiers

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éutili-sables de manière à en garantir une reconfiguration rapide et performante.

Vos processus métiers vous permettent-ils de réagir rapidement aux condi-tions 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 four-nisseurs et les partenaires. Enfin, surveillez le processus en fonction d’indi-cateurs de performance clé adaptés et suivez les performances.



Utilisateurs

1��

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

IntroductionUn fabricant de motos reconnu et respecté au niveau international compte un nombre important de propriétaires enthousiastes qui souhaitent conserver leur propre iden-tité. 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éveloppe-ment de l’activité sur le marché.La société a établi de bonnes relations avec ses fournisseurs, agents, clients et inves-tisseurs. 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étiersLa 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.

•

•

•

•

•

•


1��

SOA for Profit

La solutionLa 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 pro-motion 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 expo-sant 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 rapide-ment, sans interférer avec les composants d’autres services.

Les avantagesLes 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.

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 don-nées complexes et hétérogènes d’une entreprise en tant que services réutili-sables. 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.

•

•

•

•



Utilisateurs

1�7

Mais à mesure que l’information devient un élément clé pour chaque entre-prise, il faut éviter les redondances ou contradictions car les utilisateurs doi-vent 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 entre-prise ? 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 main-tenus 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 proc-essus 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 migra-tion d’infrastructures. À cette fin, il faut séparer les informations des envi-ronnements 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

•

•

•


1��

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 com-munication auto-sécurisée, auto-réparatrice, auto-configurante et auto-optimi-sante standardisée, qui permette la transformation d’une infrastructure verti-cale, en silos, orientée applications vers une approche plus horizontale.

L’information comme service chez un opérateur de télécommunications

IntroductionGrâce à plusieurs millions de clients connectés, ce grand opérateur de télécommuni-cations 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 grou-pes, de petites et moyennes entreprises et des organismes publics.

Les enjeux métiersLa société devait réagir aux pressions externes liées à la réglementation et à la concur-rence 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écommuni-cations, 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 ren-tables, 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 solutionUn 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.

1��

Les avantagesEn 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 à ratta-cher 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 natio-nales 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).

9.3.4 Connectivité

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’envi-ronnement 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 Connecti-vité. 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à.



Utilisateurs


1�0

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élio-ré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

IntroductionFabriquer 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 appa-reils é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 chif-fre d’affaires total et sont donc essentielles pour le développement de l’activité.

Les enjeux métiersSur 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 augmen-tation 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).

•

•

•

•

1�1

Au total, la société a identifié 14 interfaces à créer. Comme le projet devait être finalisé 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’acqui-sition 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 solutionLa 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 mes-sages 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 utilisa-teurs 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éutili-sation 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é.

9.3.5 Réutilisation

Créer des composants réutilisables signifie créer des fonc-tions ou un ensemble spécifique de fonctions, et proposer des interfaces stan-dards 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 exis-tante. Pour ce faire, il faut repenser les capacités redondantes, d’exposer



Utilisateurs


1�2

SOA for Profit

et de promouvoir les fonctionnalités communes et de concevoir de nouvel-les 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 concur-rence.

Il est essentiel de diminuer les coûts, de réduire la durée des cycles de déve-loppement et d’élargir l’accès à des applications de base en offrant des oppor-tunité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 entre-prise ?

Il réduit les coûts de maintenance en éliminant les systèmes redon-dants.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

IntroductionUne 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.

•

•

•

•

1��

Les enjeux métiersPartout 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 services 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évelop-pement 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 avantagesPar 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 mul-tiples.


1��

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éces-sité 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 investis-sements 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.

1��

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 par-cours est semé d’embûches. Si vous gérez correctement les risques, vous pour-rez 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 semai-nes 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’ac-tivité 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 com-pé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 ont-ils été étudiés suffisamment en profondeur ? Des tests d’efficacité, de perfor-mance 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-

•

•

1��

SOA for Profit

tiques et les fonctions requises pour satisfaire aux besoins explicites ou impli-cites (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 appro-che 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 pro-cessus « 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éparte-ment 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 domma-ges 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 suf-fisamment bon ? Lorsque vous testez une architecture SOA, vous devez ali-gner 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.

1�7

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 testsAvec 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 sys-tè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 asso-ciées.Constitue une base solide pour l’avenir, ce qui vous évitera de devoir réin-venter 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 [Koo-men 2006]. On peut résumer cette approche de la façon suivante :

TMap est basée sur une approche BDTM (Business-driven Test Manage-ment – pilotage des tests par les objectifs métiers).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 essen-tiel). Le modèle du cycle de vie TMap est utilisé dans la description du pro-cessus de test. Par ailleurs, il faut mettre en place plusieurs aspects relevant du domaine des infrastructures, de la technique et de l’organisation pour

•

•

•

•

1.

2.�.�.


1��

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 techni-ques, de procédures, de structures organisationnelles, d’environnements et d’outils de tests (troisième point essentiel). TMap est également un outil flexi-ble 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éthodeadaptative

flexi

ble

Guide pour achever le processus de test

Gestion des tests parles 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 uti-les, les tests doivent couvrir toutes les caractéristiques et parties d’un service

1��

(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 commen-cer. 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 économi-ques. 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 – pilo-tage des tests par les objectifs métiers), il ne faut jamais perdre de vue l’ob-jectif 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.


200

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’évolutionExigences

Métiers, etc.1. Analyse des risques d'un produit

2. Stratégie:a. choisir les niveaux de testb. choisir un test rapide/approfondic. é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.

Résultats, Risques, Temps et Argent

Client

Figure 10.2 : Étapes de l’approche BDTM

Nous allons maintenant expliquer dans les trois sections qui suivent, les éta-pes 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éristi-ques 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é.

201

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érale-ment 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 person-nes 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.

•

•

•

•

•


202

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 service (technique ou métier)

Risque d’échec/dommage 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 stra-tégie de test, on trouve un autre avantage : les différentes parties sont davan-tage sensibilisées aux risques et aux conséquences possibles. Une liste com-mune et largement soutenue des principaux risques avec leurs classifications est ainsi constituée. Pour le reste du test, cette démarche facilite l’engage-ment 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.

20�

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, factu-ration), 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éris-tiques qualité pertinentes. Autrement dit, quels aspects l’activité de test doit-elle couvrir pour atteindre les objectifs ? En général, la caractéristique « fonc-tionnalité » ou « exactitude » est la bonne. Le responsable du test doit expliquer que d’autres caractéristiques comme les performances, la convivia-lité et la sécurité peuvent aussi convenir, suivant leurs risques. Par exemple, la performance est-elle un problème pour le processus métiers Comman-des ?

Une fois toutes les caractéristiques de test sélectionnées pour chaque objec-tif, 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 tech-niques 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 ser-vice métier est divisé en plusieurs parties, par exemple les parties fonction-nelles 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.


20�

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 testUne 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 (utilisa-teur et/ou production). Tout d’abord, il faut déterminer dans un plan princi-pal, 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.

20�

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éci-fique. 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 nom-bre 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 four-nisseur d’un service est-il responsable du niveau de test ou celui-ci incombe-t-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 approfondisPour 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 enreg-istrés dans un tableau de stratégie par niveau de test (cf. Tableau 10.3).

Caractéristique/ composant

Classe de risque

Révision Test des dévelop-pements

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


20�

SOA for Profit

Dans le Tableau 10.3, le test des développements comprend des tests uni-taires 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 effec-tué à 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 utilisa-teurs (finaux) possèdent ces connaissances, mais ils craignent souvent, à cause de l’environnement technique, de tester individuellement chaque ser-vice. 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 environne-ment de test représentatif, stable et fidèle aux conditions de production, nécessite une grande coordination entre entreprises, départements et équi-pes. 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’in-frastructure et l’environnement.

207

É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 pre-miers 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 fonc-tion 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 testLorsque 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.


20�

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 processusLa qualité et les risques du ou des services testésLa 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’entre-prise. 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’entre-prise 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 modi-fiés mis en place etc. Vous devez savoir qu’une analyse des risques d’un pro-duit et une stratégie de test ne reflètent qu’une situation à un moment donné.

•

•

•

•

•

•

20�

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 environ-nement adapté. La mise en place et le maintien de cet environnement se tra-duisent 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 environne-ment 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 doi-vent relever quelle que soit la situation. Comme la chaîne couvre une multi-plicité 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.


210

SOA for Profit

Pour bien organiser cette démarche, les différents acteurs doivent préalable-ment 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 change-ment. 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 simple-ment à 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 qua-tre 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.

•

•

•

•

211

Réagir aux changementsAu 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 pos-sibles. 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 per-met 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 bat-teries 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.


212

SOA for Profit

Capitaliser sur les retours d’expérienceVous 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’utiliserPendant les tests SOA, il faut pouvoir essayer avant d’utiliser. Ici, les princi-paux 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’ap-pliquer à 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éter-miner 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 crucia-les, 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 :

21�

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 cou-vrent 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. Pen-dant 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éter-miner (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 crois-sant 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 doi-vent 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 chan-gements pour le bénéfice des tests. Les quatre qualités nécessaires aux tes-teurs 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.

1.2.�.�.

•

•

•

•


21�

11 Les dix meilleures choses à dire pour se faire 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’en-tre 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 :N’en parlons pas au métier.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.Lançons-nous avec la SOA à l’assaut de cibles mobiles.Que mille services éclosent.Orientons-nous services sans architecture.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 remet-tre en œuvre totalement leur informatique à l’aide des principes SOA sans en avertir le métier.

1.2.�.�.�.�.7.�.�.10.

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 informatiqueSi 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évelop-per, 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 infor-matique 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 ser-vice informatique. Il devrait être impossible au service informatique d’entre-prendre une transformation architecturale sans impliquer le métier.

FinancementUne autre raison pour laquelle il devrait être impossible de mettre en œuvre des changements si importants au sein du service informatique sans impli-quer 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

SOA for Profit

21�

217

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 demeu-reront et forceront le service informatique à répliquer ces silos dans l’archi-tecture. Dans de telles circonstances, la réutilisation reste une illusion.

Au débutLe 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 informati-que 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 ser-vice informatique en commençant et en passant ensemble par la phase d’ap-prentissage.

S’adresser au métierPar 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 dia-logue 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 dialo-gue, 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-


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 infor-matique » ; 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 dialo-gue 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ègleC’est très rare, mais au cas où une entreprise disposerait d’un environnement infor-matique homogène (exclusivement en ordinateur principal ou exclusivement en SAP, par exemple), la SOA est pratiquement inutile. Il n’existe habituellement aucun pro-blème d’intégration, la perception du système est claire et la réactivité aux change-ments 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’el-les é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-

SOA for Profit

21�

21�

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 retar-dera les améliorations réelles de plusieurs années. Il existe quelques exem-ples de sociétés informatiques qui ont mis en œuvre des projets SOA finale-ment 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évolutionUn 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 à entre-prendre 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 pro-posés par l’entreprise. Ces services sont autant en rapport avec les produits que les processus. Mais, surtout, les services concernent les capacités (fonda-mentales) 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 lors-qu’elle est appliquée à l’entreprise dans son intégralité, une vision des pro-cessus 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


220

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éces-site 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 don-né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 comp-table 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 unique-ment concerner les données, mais également les processus, la qualité atten-due, 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.

221

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’en-treprise.

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 « servi-ces ». 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 servi-ces offriront une valeur métier.

De fait, comme nous l’avons déjà dit, pour tenir les initiatives bien intention-nées à l’écart du service informatique, l’entreprise doit prendre ses respon-sabilités en termes d’intégration et de SOA. L’entreprise doit prendre l’ascen-dant 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’in-tégration. Bien souvent, cela est établi dans des structures de gouvernance et des mises en place de bons processus architecturaux. Une entreprise se com-portant 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ère-ront ê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 connais-sance technologique solide. Ils ont commencé par la programmation de ser-vices 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’uti-lisation de la SOA. Mais leur expérience en matière de processus métiers, gouvernance ou changements organisationnels est insuffisante.


222

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 plu-tô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 gouver-nance doit être appliquée, dont une stratégie informatique utile doit être choi-sie, etc. Naturellement nous pensons qu’une connaissance livresque ne peut qu’aider, mais l’expérience de votre entreprise est bien plus importante. L’ar-chitecture 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 entre-prises commencent par échanger des expériences au sein d’un secteur d’in-dustrie 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 nou-velle est de mettre en place un centre de compétence SOA (ou centre d’ex-cellence 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’utili-sation 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.

22�

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éve-loppeur, à 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 égale-ment 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’ali-gner 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 à dis-tinguer 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 com-posants 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 dura-bilité est supérieure aux autres. Cette recherche des aspects changeants et constants au niveau informatique et métier correspond véritablement à « l’ar-chitecture émergeante » : trouver et définir les structures qui dureront plus longtemps que des changements au jour le jour.


22�

SOA for Profit

L’architecture métier consiste essentiellement à trouver les capacités et pro-cessus fondamentaux : que fait véritablement votre entreprise et que fera-t-elle 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ïnci-der 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’In-ternet, de nouvelles solutions ont abondé, faciles à établir, à déployer, émer-geant 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 infor-matique. 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

22�

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 ser-vices dès le début ».

Que faire ?Certaines mesures permettent de garantir la bonne gestion de votre porte-feuille 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 survivrontAvec la SOA, l’ensemble des services proposés par l’informatique doit coller à la demande de l’entreprise. Une entreprise en perpétuel changement impli-que également que le portefeuille de services soit continuellement sous sur-veillance : 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 plu-part des articles tirés de la presse et d’Internet concernent l’outillage, la tech-nologie 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.


22�

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 entre-prise. 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é servi-ces ».

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

227

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’en-contre 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, ren-table 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 monu-mentale.

Une note en passantAlors 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 excep-tions à cette règle (pas dans votre entreprise) : dans certains cas, des fournisseurs externes peuvent proposer des services qui correspondent si parfaitement au proces-sus 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 banali-sation se produit très rapidement, les fournisseurs de services seront impatients de combler les écarts qui apparaissent dans ce nouveau marché banalisé. Et dans cer-tains 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.


22�

12 Le voyage continue

Quel bilan, quelles perspectives ? Dans le présent ouvrage, nous avons mon-tré 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égra-tion 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éutili-ser des composants chaque fois que l’opportunité se présente. Commencer à utiliser cette architecture amorce une transformation qui nécessite une pla-nification 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 ali-gné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’appli-quer 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’abs-traction adapté, vous devez comprendre votre métier (chose facile) et trou-ver 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 ser-vices 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’en-treprise 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.

2�0

SOA for Profit

Nous avons présenté un modèle intitulé bus de services humain (Human Ser-vices 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 matu-rité énumérera les aspects de entreprise qui doivent être améliorés afin d’at-teindre 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é per-met 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é gra-duellement 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étierLa lente évolution de l’informatique ne constituant plus un obstacle pour elles, les entreprises changeront rapidement et pourront mieux s’adapter aux

2�1

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 justi-fie. 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étierLa distinction entre informatique « infrastructurelle » et informatique « inno-vante » 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’effica-cité et de rendement pour s’attaquer à des problèmes vastes et coûteux, tels que la mondialisation, le vieillissement et la menace du changement climati-que.

Le nouveau monde d’InternetEn fournissant des services qui utilisent la SOA, les entreprises seront par-faitement é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 pou-vez 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 intuitionGrâ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 sim-ple, 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.


2�2

SOA for Profit

Non seulement Internet permet une présence étendue sur le marché inter-national, 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 don-neront les clés du marché. Des offres orientées services, permettant la com-binaison et la personnalisation, rendront possible cette évolution.

Nouvelles générationsDe 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 informati-ques suivent facilement leur attentes dans tout ce qu’ils font, en s’adaptant aux processus individuels et aux préférences personnelles. Leurs mouve-ments 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’informatiqueUne 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 marchan-dises ne seront plus spécifiques à une unité ou à une entreprise. Ils consti-tueront une infrastructure, prête à être utilisée en cas de besoin, optimisée

2��

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’informa-tique.

Dans le présent ouvrage, nous avons abordé les conditions les plus importan-tes 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œuvra-ble et la relier aux développements informatiques.

•

•


2��

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, com-mencez 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.

•

2��

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éces-saire, 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 prio-ritaires à 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 pro-gressive se lit de gauche à droite.

Il faut observer les règles suivantes lors de l’application du modèle de matu-rité :

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,

•

•

2��

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.

Secteur clé

Stade

0 1 2 3 4 5 6 7 8 9 10 11 12 13




4 Développement de l’architecture A B C



A B C



A B C D



A B C D

11 Budgétisation et planification A B C D




A B C D


A B C D



A B C


A B C


A B C


A B C

Figure 13.1 : Modèle de maturité SOA

2�7

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 matu-rité 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 SOAUn budget et du temps sont mis à disposition pour un nombre limité d’ini-tiatives 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é accep-tée comme une future orientation architecturale privilégiée pour l’entre-prise.

Points de contrôleUn 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’architec-ture privilégié pour le métier et le service informatique et la direction géné-rale de l’entreprise promeut ce choix.

•

•

•

•

•


2��

SOA for Profit

Points de contrôleLa SOA est-elle activement promue par la direction métier et service infor-matique ?Lors de la mise en œuvre d’une nouvelle fonctionnalité, la SOA constitue-t-elle le choix standard de type d’architecture privilégié ?

C : L’approche SOA est intégrée dans les processus de l’entrepriseLe 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éces-saire.

Points de contrôleD’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 projetsLes 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’infor-mations 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ôleLes 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 ?

•

•

•

•

•

•

•

•

•

2��

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é suffisam-ment régularisé pour que les architectes puissent disposer d’un retour d’in-formations et adapter l’architecture SOA, le cas échéant.

Points de contrôleL’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 projetLa création de l’architecture de départ du projet est un processus conjoint dans lequel les architectes et les principales parties prenantes sont impli-qués.

Points de contrôleLes architectes aident-ils les développeurs à appliquer l’architecture d’en-treprise 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 informatiqueUn dialogue permanent entre les architectes et les principales parties pre-nantes 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ôleExiste-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 ?

•

•

•

•

•

•

•


2�0

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 processusLe 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ôleLe choix de la SOA pour l’entreprise en tant que style d’architecture pri-vilé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’architectureLe 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ôleLe 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 parta-gé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 organi-sationnels.

•

•

•

•

•

•

•

•

2�1

Points de contrôleLa 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 projetsLa 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ôleToutes 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 transversalMettre 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ôleExiste-t-il des principes et modèles généraux de SOA au sein de l’entre-prise 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’archi-tecture d’entreprise ?

C : Architecture en tant que processus de facilitationProduire 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

•

•

•

•

•

•

•

•

•


forme d’architecture mise en place, le but et la fonction de l’architecture sont clairs dès le départ.

Points de contrôleLes 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 informatifL’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ôleUne 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 mem-bres des équipes ?

B : Architecture utilisée pour orienter le contenuL’architecture SOA est véritablement utilisée pour orienter les options rele-vant de la SOA dans les projets. Les projets doivent être conformes à l’archi-tecture.

•

•

•

•

•

•

•

SOA for Profit

2�2

2��

Points de contrôleL’architecture d’entreprise est-elle utilisée pour guider les développe-ments 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’entrepriseL’architecture basée sur la SOA fait partie intégrante du pilotage de l’entre-prise. C’est un facteur déterminant dans les processus de décision.

Points de contrôleL’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éesDes 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ôleDes 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 ser-vices ?Des méthodes et outils sont-ils utilisés pour contrôler l’utilisation des services ?

•

•

•

•

•

•

•

•

•


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 proces-sus 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ôleLes 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’architec-ture.

Points de contrôleLa 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érieureL’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.

•

•

•

•

•

•

•

•

•

SOA for Profit

2��

2��

Points de contrôleA-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ôleLes 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’entre-prise ?

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ôleUn 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’architec-ture ?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’entrepriseLa 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ôleLa 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, pro-cessus de gestion) est-elle prise en compte dans des considérations concer-nant la qualité de la SOA ?

•

•

•

•

•

•

•

•

•

•


13.9 Gestion de portefeuille de services

A : Les durées de vie des services correspondent à celles des applications qui les livrentLes 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ôleLa gestion d’un service est-elle liée à une application offrant ledit ser-vice ?Si nécessaire, un service est-il adapté lorsque l’application offrant ledit service est adaptée ?

B : Accords sur les niveaux de servicesLa 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 condi-tions de livraison du service.

Points de contrôleExiste-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 ser-vices sont prises en fonction du portefeuille complet de services.

Points de contrôleLes 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 ?

•

•

•

•

•

•

•

•

SOA for Profit

2��

2�7

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ôleEst-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’utilisa-tion ?Les utilisateurs et fournisseurs de services peuvent-ils négocier les condi-tions 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’architec-ture sont également identifiés.

Points de contrôleL’architecture d’entreprise actuelle (en l’état) est-elle décrite en termes de processus, services, applications, données, infrastructure technique et rela-tions entre ces derniers ?Les goulots d’étranglement de l’architecture d’entreprise actuelle sont-ils évidents ?

B : Vision des évolutions à court termeOutre l’architecture actuelle, un aperçu des développements SOA à court terme et de leur niveau d’influence sur l’architecture actuelle s’impose. Par-tant, 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ôleConnaî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 disponi-bles aux domaines où la SOA est en cours de mise en œuvre ?

•

•

•

•

•

•

•

•


C : Vision de l’architecture à long termeConformément à la stratégie de l’entreprise, une architecture d’entreprise est mise en place pour identifier les principales caractéristiques des change-ments 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ôleUne architecture de référence à l’échelle de l’entreprise englobant la des-cription 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 termeL’entreprise dispose d’un processus grâce auquel des considérations archi-tecturales permettent un alignement permanent des objectifs métiers et stra-tégiques sur les processus actuels, le schéma organisationnel, la fourniture d’informations et l’infrastructure technique d’une entreprise.

Points de contrôleL’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éci-sant 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ôleLes services et les applications sont-ils uniquement conçus lorsqu’un busi-ness case clair les concernant se présente ?

•

•

•

•

•

SOA for Profit

2��

2��

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ôleY 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éci-fiées ?L’entreprise a-t-elle à sa disposition un processus de test de services for-malisé ?

C : Le processus d’architecture soutient l’entrepriseLes 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ôleL’entreprise dispose-t-elle d’un processus d’architecture décrivant les éta-pes 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ôleLes évolutions métiers se produisent-elles uniquement lorsque l’architec-ture a été établie à cette fin ?

•

•

•

•

•

•

•


2�0

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 impactChaque projet ayant un impact SOA est testé selon son rendement (tel que le RCI, rendement du capital investi).

Points de contrôleChaque projet SOA est-il testé selon certains objectifs de rendement ?Un budget est-il établi pour chaque projet SOA ?

B : Spécifique au projet SOAChaque projet SOA est précédé de la formulation d’un calendrier prévisionnel et de l’établissement d’un budget.

Points de contrôleUn calendrier prévisionnel est-il formulé pour chaque projet SOA ?L’évolution d’un projet SOA est-elle surveillée ?

C : Générique entrepriseIl existe une méthode de planification et de budgétisation standard pour les projets SOA au sein de l’entreprise.

Points de contrôleExiste-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étisationLa budgétisation et la planification des projets SOA peuvent être profession-nalisées à l’aide d’une révision structurelle de la qualité de planification.

•

•

•

•

•

•

•

•

•

2�1

Points de contrôleExiste-t-il un processus structuré pour bénéficier de retours d’informa-tions 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éti-sations et les anciens calendriers prévisionnels des projets SOA ?

13.13 Technologie et standards

A : Technologie ad hoc choisie en cas de besoinUne technologie et des standards SOA sont choisis lorsqu’un problème concret se pose.

Points de contrôleLes 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ôleLes choix concernant les technologies et standards SOA sont-ils unique-ment 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éeLe choix de standards et technologies découle d’une stratégie à l’échelle de la SOA.

Points de contrôleLes choix de technologies et standards SOA sont-ils déterminés en fonc-tion 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 ?

•

•

•

•

•

•

•

•


2�2

SOA for Profit

D : Anticipation de changements technologiques et adoption de nouveaux standardsDe 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ôleLes 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éeLa réutilisation et la subdivision ont lieu, mais plus ou moins par hasard.

Points de contrôleExiste-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ôleUn 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 ser-vices 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 subdivi-sion se fassent également au niveau métiers.

•

•

•

•

•

•

2��

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 couranteLa 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 incor-poré dans la méthode de fonctionnement standard de l’entreprise, en ce qui concerne le changement.

Points de contrôleAu 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 silosDes 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ôleLes services métiers sont-ils en cours de conception pour rendre les sys-tè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 transversauxLes 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.

•

•

•

•

•

•


2��

SOA for Profit

Points de contrôleLes services métiers sont-ils en cours de conception pour soutenir spéci-fiquement 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ôleLe 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ôleGrâ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 reti-rés par les services métiers et le service informatique en parfaite collabo-ration ?

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 tech-niques dans ce genre de système.

•

•

•

•

•

•

•

2��

Points de contrôleL’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ôleLes 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 ser-vices métiers alignés sur les processus métiers qu’ils doivent soutenir.

Points de contrôleLes 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ôleLes 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 ?

•

•

•

•

•

•

•


2��

SOA for Profit

13.17 Sécurité

A : RéactiveL’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ôleAu 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 : IndividuelleL’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ôleAu 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 servi-ces ?

C : CollectiveDes 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é amor-cé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’entre-prise.

•

•

•

•

•

2�7

Points de contrôleDes 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 : ProactiveL’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 protec-tion de l’information. Les directeurs métier et processus sont responsables des incidents de protection des informations.

Points de contrôleL’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 infor-mations à l’échelle de l’entreprise ?La responsabilité de la sécurité des informations est-elle intégrée à l’en-treprise ?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ôleUn 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 appli-quer la SOA à leur travail. En moyenne, tous les informaticiens influencés par la SOA ont travaillé sur la SOA au cours d’un projet.

•

•

•

•

•

•

•

•


2��

SOA for Profit

Points de contrôleDes informaticiens en nombre suffisant ont-ils accumulé une expérience pratique de la SOA ?

C : ExpérimentéeLes 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 informati-ciens maîtrisent la SOA.

Points de contrôleUn 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’entre-prise traite la SOA ?

13.19 Compétence SOA des professionnels métiers

A : BasiqueUn niveau basique d’expertise a été atteint. Les professionnels métiers connaissent la SOA.

Points de contrôleUn 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 pro-fessionnels métiers influencés par la SOA ont travaillé sur la SOA au cours d’un projet.

Points de contrôleUn nombre suffisant de professionnels métiers ont-ils accumulé une expé-rience pratique de la SOA ?

•

•

•

•

•

•

2��

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 profes-sionnels métiers maîtrisent la SOA.

Points de contrôleUn 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éeLes gens connaissent la SOA de façon sporadique au sein du service infor-matique. 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ôleLa majorité du service informatique connaît-elle la SOA ?

B : Sensibilisation au niveau de l’organisation du serviceAu 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ôleLa 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 SOALa SOA profite d’un large soutien au sein du service informatique. Les avan-tages 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.

•

•

•

•

•


2�0

SOA for Profit

Points de contrôleLa 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-t-elle sur une large base de soutien ?

13.21 Connaissance et état d’esprit SOA des professionnels métiers

A : Sensibilisation limitéeLes 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ôleLa majorité du service métier connaît-elle la SOA ?

B : Sensibilisation au niveau de l’organisation du serviceAu sein du service métier, les gens sont très sensibilisés à la SOA et aux avan-tages 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ôleLa 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ôleLa 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 ?

•

•

•

•

•

•

•

2�1

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éveloppe-ment. 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’at-tention 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’en-treprise 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.


2��

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/developer-

works/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 tran-

snational solution, Harvard Business School Press, 2002

Belbin, Meredith, Management Teams, Oxford, 2004

Berg, Martin van den et Marlies van Steenbergen, Building an Enterprise Architec-

ture 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://soaprojectman-

ager.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.zap-

think.com

Broadbent, Marianne et Peter Weill, Leading Governance Business and IT Proc-

esses, 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

2��

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-Vernet-

zung, 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 ID-

number SPA-19-5971, 2003

Gartner, A Portal May Be Your First Step to Leverage SOA, Gartner Research ID-

number 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 ID-

number 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-soa-

whitepaper.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-work-

place.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

2��

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_Alli-

ances.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

2�7

A

administrateur registre 144

administrateur système et base de

données 142

agilité 55

alignement métier (domaine de matu-

rité SOA) 154

analyse des risques d’un produit 200

analyste d’entreprise 141

animateur des transferts de compéten-

ces 142

approche

bottom-up 177

middle-out 177

top-down 177

architecte d’entreprise 137

architecture

de domaine 78

d’entreprise 74

de démarrage projet 83, 94

de référence 79

développement 153

en tuyaux de poêle 100

en silos 100

orientée services (SOA) 19

utilisation de l’ 153

associés (processus) 107, 108

asynchrone 46

B

BDTM 197, 199, 200, 208

base (choix de) 173, 175

bottom-up (approche) 177

budgétisation et planification (domaine

de maturité SOA) 155

bus d’orchestration et de collaboration

(COB) 126, 127

bus de services d’entreprise (ESB) 81

bus de services humains (HSB) 126

business model 98, 101, 105

C

cartographie

domaine métier 102

potentiels 103, 109

CBM 111

centre d’excellence 91

chaîne de valeur 106

champion du service métier 139

chaos (cas de figure) 160

chiffre d’affaires (augmentation du) 32

choix de base 173, 175

COB 126

COE 91

collaboration 181

Component Business Modelling (CBM)

111

concepteur de flux de processus 143

configuration dispersée 48, 125

conformité 32

couches 48

cycle de vie des services (gestion du)

71

D

décomposition et réutilisation

(domaine de maturité SOA) 155

déployeur de services 142

destruction proactive 55

développement

avec architecture (processus DYA) 74

sans architecture (processus DYA) 75

développement de nouveaux produits

32

Index

développeur de services 141

dialogue stratégique (processus DYA)

74, 75

domaine (architecture de) 78

E

EAI 48

écueils 215

engagement et motivation (domaine de

maturité SOA) 152

entreprise (architecture d’) 137

entreprise dynamique (DYA) (architec-

ture d’) 74

entreprise orientée services 99, 100,

123

ESB 81

F

façonneur d’outils 142

feuille de route 171

flair développé 231

G

gestion de la qualité (domaine de matu-

rité SOA) 154

gestion des tests par l’activité (BDTM)

199

gestion du portefeuille de services


gouvernance 61, 66, 84, 89, 92

d’entreprise 66

mécanismes 94

H

HSB 126

I

information comme service 186

intégration d’applications d’entreprise

(EAI) 48

M

matrice Gain/Facilité 115

maturité 150

modèle 163

niveau 151

point de contrôle 152

secteurs clés 152

middle-out (approche) 177

modèle de maturité 163

modèles industriels 121

N

normes 49

nouveaux produits (développement de)

32

O

optimisation métier 97

outils architecturaux (domaine de

maturité SOA) 154

P

plan d’urbanisme 78

points d’entrée 179

points de contrôle de niveaux de matu-

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

Project Start Architecture (PSA) 83, 94

projet pilote 175

projets de disponibilité 178

Q

qualité (gestion de la) (domaine de

maturité SOA ) 154

qualité du service 73

2��

2��

R

RACI 85

RAEW 85

Rational Unified Process 49

réduction

des coûts 32

des risques 32

réference (architecture de) 79

registre des services 73

régression (test de) 206

relation avec les projets (domaine de

maturité SOA) 153

responsable du registre de services 140

réutilisation 51, 53, 191

risques 195

rôles 137, 139

rôles et responsabilités (domaine de

maturité SOA) 153

S

sécurité de l’information (domaine de

maturité SOA) 156

services 46, 109, 128, 129, 186

architecturaux (processus DYA) 74

gestion du cycle de vie 71

qualité 73

réutilisation 51, 53, 191

silos 112

SOA

achetée 65

administrateur système 143

brute 65

compétences (domaine de maturité

SOA) 156

état d’esprit et connaissances


gouvernance 61, 66, 84, 89, 92

maturité seceurs clés 150, 152

redondante 65

responsable projet 143

stratégie de test 198, 204

souplesse accrue 32

souplesse du système d’information


spécialiste sécurité 141

stratégie 89

stratégie en cascade 108, 117

T

technologie et standards (domaine de

maturité SOA) 155

test 196, 197

approche 197

environnement 209

stratégie 198, 204

testeur d’interopérabilité 144

testeur de l’intégration des services

142

TMap 197, 198

top-down (approche) 177

tuyaux de poêle (architecture en) 100

U

utilisation de l’architecture 153

V

vision d’entreprise 32

vision de l’architecture SI (domaine de

maturité SOA) 154

W

Web 2.0 131, 132

X

XML 46, 193

271

À propos d’IBM

Chez IBM, nous nous efforçons d’être les leaders en matière d’invention, de déve-

loppement 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’in-

novation. IBM définit sa vision en s’appuyant sur les problèmes, processus et exploi-

tations rencontrés dans divers secteurs, puis invente et met en pratique une tech-

nologie 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.

27�

À 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 prox-

imité 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 sys-

tèmes.

De l’intégration d’infrastructures techniques à la mise en œuvre de systèmes

informatiques : conseil, architecture technique, ingénierie, intégration, installa-

tion et administration de systèmes et réseaux, gestion de mise en œuvre et assist-

ance utilisateur.

Haute Technologie ou Conseil de Haute Technologie.

Développement et Recherche Extérieurs et Conseil en Innovation. R&D tech-

nique et scientifique, conception mécanique, développement de systèmes com-

plexes.

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

•

•

•

Martin van den BergMartin van den Berg occupe un poste d’Ar-chitecture 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 entrepri-ses lors de la professionnalisation de l’archi-tecture d’entreprise et de la mise en œuvre de l’architecture orientée services. Il est l’un des fondateurs de la DYA (architecture dynami-que) ainsi que le coauteur de « Dynamic Enterprise Architecture, How to make it work » et « Building an Enterprise Architec-ture Practice ». Martin van den Berg est éga-lement le président du département architec-ture de la Dutch Computer Society. Martin a publié de nombreux articles et est un interve-nant recherché pour les séminaires sur l’ar-chitecture.

[email protected]

Norbert BiebersteinNorbert Bieberstein travaille pour l’organisa-tion 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 à par-tir 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, coor-donné le numéro 44-4 consacré à la SOA de IBM Systems Journal, et a été l’auteur princi-pal 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 Applica-tions for Grid Computing with Globus (SG24-6936-00), et a publié l’ouvrage CASE-Tools (ISBN : 3446175261). Il a commencé chez IBM en qualité de conseiller en technologie logi-cielle 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 fournis-seur de logiciels de plus petite envergure et

en tant que programmateur scientifique à l’Université de Technologie d’Aachen (RWTH), où il a également obtenu son Mas-tère en mathématiques et en géographie. Il vient de terminer un programme de Corpo-rate MBA au Henley Management College au Royaume-Uni.

[email protected]

Per BjörkegrenPer Björkegren est l’un des principaux Archi-tectes d’Entreprise et stratégistes informati-ques en Suède. Il est chef de la pratique de l’Architecture et de la Gouvernance Informa-tique 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’infor-matique, l’architecture d’entreprise et la ges-tion informatique. Per a une connaissance solide de l’informatique, allant du développe-ment 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 GaultierJean-Marc Gaultier est le Vice-président res-ponsable de l’alliance du Groupe Sogeti avec IBM. Il a une connaissance étendue des ventes internationales dans le domaine de l’informa-tique avec une expérience en gestion des ven-tes 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éten-ces et ses ventes tournant autour de la tech-nologie IBM.

[email protected]

À propos des auteurs

27�

27�

Lon L. HoldenLon 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 tech-nologie entre en jeu pour fournir une valeur ajoutée importante aux clients, tout en propo-sant une différentiation concurrentielle dans les offres de l’intégrateur. Lon a une grande expérience dans le secteur du conseil infor-matique comprenant le développement logi-ciel, 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 JuanManuel de Juan est Directeur Technique et membre du Bureau d’Innovation Informati-que (IT Innovation Office) chez Sogeti Espa-gne. Dès ses débuts dans l’informatique, il a consacré ses efforts professionnels à résou-dre l’intégration entre les systèmes, que ce soit en qualité de développeur logiciel, d’ana-lyste 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 KoomenTim 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 hol-landais, anglais, allemand et japonais, co-ré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 États-Unis. 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 MayerCraig 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’infor-mation et d’exploitation dans diverses indus-tries. Son expérience première concerne l’ali-gnement de l’entreprise et de la stratégie technologique d’information ; il possède aussi une connaissance approfondie de la réorga-nisation 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 éga-lement très compétent en matière d’efficacité et d’intégration de processus métiers, Sarba-nes-Oxley – CobIT – ITIL évaluation et conformité, kaizen et gemba kaizen (amélio-ration permanente), et de tests de logiciels basés sur la qualité/les risques. Craig est titu-laire d’un doctorat (ABD) en anthropologie de l’Université méthodiste du Sud (Dallas, Texas).

[email protected]

Bruno RizziBruno 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 quali-métrie, la gestion de projet et l’architecture. Il a travaillé en qualité d’expert JEE pour plu-sieurs grandes sociétés françaises. Bruno par-tage désormais son temps entre le développe-ment de l’offre SOA en entreprise et le conseil en architecture des clients de Sogeti.

[email protected]

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 infor-matique, il occupe plusieurs fonctions : archi-tecte logiciel, directeur de projet, concepteur et développeur. Il est responsable de l’évalua-tion d’opportunités SOA chez Sogeti et coor-donne 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 OmmerenErik van Ommeren est Directeur Innovation chez Sogeti USA LLC. Il est responsable de VINT, l’Institut d’Analyse des Nouvelles Tech-nologies 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 services chez Sogeti aux Pays-Bas. Erik a une grande connaissance en informatique. Son expérience va du développement logiciel à l’aide de tech-nologies différentes, en passant par l’architec-ture et la gestion (de projet). Il passe une par-tie 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.

[email protected]

Philippe RavixPhilippe Ravix est architecte SI et SOA Ser-vice 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 transforma-tion. Philippe est également formateur, inter-venant sur des événements SOA et auteur de documents de présentations techniques.

[email protected]

Guillaume SchottGuillaume 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’archi-tecte pour les postes de travail de nouvelles succursales. Il a rejoint le bureau du Luxem-bourg en 2000 et participe à de nombreuses mises en œuvre de systèmes de banque en ligne multivoie en qualité d’architecte princi-pal. Ces projets, actuellement en cours de pro-duction, 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 (cer-tifié) 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 technolo-gie. Outre cela, il est également l’un des mem-bres 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]

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 coauteur de TMap Next (en hollandais, anglais et allemand) (à paraître bientôt) et de « Inte-grated Test Design & Automation: Using the TestFrame method », traduit en Hollandais et en Anglais. Michiel est professeur et présen-tateur. 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]

27�

Sogeti Pays-Bas Martin van den BergSogeti USA Erik van Ommeren

IBM Software Group Allemagne Norbert Bieberstein

Avec les contributions dePer Björkegren Sogeti Suède •Jean-Marc Gaultier Sogeti USA •Lon Holden IBM Software GroupUSA • Manuel de Juan SogetiEspagne • Tim Koomen SogetiPays-Bas • Craig Mayer Sogeti USA• Philippe Ravix Sogeti France •Bruno Rizzi Sogeti France •Gonzalo Rodriguez SogetiEspagne • Guillaume Schott SogetiBelux • Gerard Smit IBM Pays-Bas •Michiel Vroon Sogeti Pays-Bas

L’architecture orientée services (SOA) est en train de devenirl’architecture informatique dominante, ce qui a des implicationsconsidérables pour le fonctionnement des organisations.Lentement mais sûrement, l’informatique gagne en maturité etdevient ce support à la fois flexible, stable et fiable dont touteentreprise a besoin. Dans le même temps, l’informatique revienten force dans les processus d’innovation au sein de l’entreprise.Pour toute organisation, la SOA constitue à cet égard un pasdécisif dans la bonne direction à condition de ne pas en faireune simple question de technologie. Bien sûr, les défistechnologiques sont importants à relever, mais l’apportessentiel de la SOA se situe ailleurs : une prise en compteglobale de la façon dont l’informatique peut devenir l’élémentclé du succès de toute stratégie d’entreprise.

SOA for Profit dévoile la nature de la SOA et illustre la valeurajoutée qu’elle apporte. Cet ouvrage pratique et pragmatiquerend 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 etde l'architecture informatiques et démontre qu'une visionélargie de la SOA est essentielle pour en tirer tous les bénéficespossibles. Ce livre raccroche l'informatique au managementgrâce à des outils et à un langage communs qui rendentpossible le dialogue stratégique que l'on retrouve à la base detoute informatique orientée métiers.

Écrit par une équipe d'auteurs de Sogeti et d'IBM, SOA forProfit est un livre concret, tiré d'une longue expérienced'entreprises et de projets bien réels.

SOA for ProfitGuide du manager pour une Architecture Orientée Services réussie SOA

for Profit

Van

den

Ber

gV

an O

mm

eren

(d

ir.)

Bie

ber

stei

n

Guide du manager pour uneArchitecture Orientée Services réussie

Ce livre est sans conteste lemeilleur livre que j’aie lu sur laSOA. C’est un livre concret, quitraite et relie les différentsaspects de cette approche SOA,depuis la stratégie et les enjeuxmétiers jusqu’à la conduite duchangement et des rôles des col-laborateurs. Les chapitres sur lagouvernance et sur préparationsont eux aussi les meilleurescontributions que je connaissesur ces sujets, avec un équilibreentre l’explication (en donnantdu sens) et l’application (en res-tant concret et synthétique).Contribution majeure qui de vraitêtre lue par tous les managersnon-informaticiens, ce livre per-met de comprendre pourquoi laSOA est fondamentalementadaptée aux mutations desentreprises d’aujourd’hui à con -dition de faire profondémentévoluer leur façon de travailler.Le style est franc et direct, avecune pointe d’humour, ce qui enfait une lecture agréable.

Yves Caseau Bouygues Telecom

Une contribution pratique etpragmatique à l'évolution de laSOA en tant qu'approche archi-tecturale créatrice de valeur pourl'entreprise. Les différentes vi -sions et les considérations infor-matiques complètes établies con -cernant la SOA s'appuient surdes exemples réels et convain-cants. Ce document constitue unguide prêt à l'emploi pour adop-ter et mettre en œuvre une SOA.C’est un document de référenceexceptionnel pour toute per-sonne désirant passer à un ni -veau supérieur d’alignement del’informatique d’entreprise et dumétier grâce à la SOA.

Henrik JacobssonShell

Mon intérêt n’a cessé de croîtreau fur et à mesure de ma lecturedu manuscrit… con clu sion : «çavalait le coup» ! L’approchebusiness, utilisateurs et organi -sation que les auteurs ontprivilégiée est très per tinente.Malgré le luxe de dé tails on n’estpas submergé de considérationstechniques : un des gros avan -tages de ce livre ! Un modèle etune mé thode pratiques de me -sure de la maturité sont présen -tés, et la liste finale de référencesest très complète et à jour. Sivous vou lez savoir pourquoi jepréfère la définition Biebersteinde la SOA, lisez le livre par vous-même. En ce qui me concerne,aucun regret…

Dr. Jan Peter de ValkING

SOA

for

Pro

fit

Documents

SOA for Profit - French version.pdf