Architecture de Sécurité - coopérer pour protéger efficacement son SI. Les Appliances dans les Infrastructures SOA

Transcription

1 IT LA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE L'INFORMATIQUE Architecture de Sécurité - coopérer pour protéger efficacement son SI Les Appliances dans les Infrastructures SOA TOP5 des anti-patterns appliqués à l ESB Les visions dynamiques de l Architecte d Entreprise La gouvernance du patrimoine applicatif - optimisation de la qualité applicative Bimestriel - novembre/décembre 2010 Le Cloud Computing privé au service des métiers n 88

2

3

4 édito Délit de Pattern-IT Avec le souci de bien faire et de faire gagner du temps, les grands cabinets de consulting industrialisent leurs activités. Eux aussi? Eh oui! Partant du principe que copier les meilleurs avec les règles qui les font gagner fera forcément d une entreprise un leader, ils vendent à prix d or des best-practices. Attention, pas n importe lesquelles : fidèles aux grandes théories, aux référentiels et patati et patata. Et le plus beau? Tous les cabinets proposent des approches sectorielles annoncées comme les plus fiables et pourtant différentes. À croire qu ils les ont analysées dans des contrées très éloignées! Autre danger de taille, l enferment dans un carcan ne risque-t-il pas de brider l initiative et l innovation? Réponse admirable : On a aussi prévu l innovation! Concept étonnant de «l encadrement de la créativité»! Faut-il pour autant jeter le bébé avec l eau du bain? Certes non. Mieux vaut une approche trop structurante que rien. Et si elle n est pas trop exotique, elle restera adaptable. Toutefois, restez souples dans l application. Les décideurs auraient tort de s en remettre corps et âme à une unique approche psychorigide. De toute façon, la confrontation avec les réalités du terrain calme les ardeurs des plus rigoristes. Dans le cas contraire, préparez donc les chèques et l échec! José Diz Rédacteur en Chef IT LA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE L'INFORMATIQUE Editeur Press & Communication France Une filiale du groupe CAST 3, rue Marcel Allégot Meudon - FRANCE Tél. : Fax. : [email protected] Rédacteur en chef José Diz [email protected] Directeur de publication Aurélie Magniez [email protected] Abonnements/Publicité [email protected] Conception Graphique Nicolas Herlem Parution IT-expert - (ISSN ) est un journal édité 6 fois par an, par P&C France, sarl de presse au capital de ,61. Avertissement Tous droits réservés. Toute reproduction intégrale ou partielle des pages publiées dans la présente publication sans l autorisation écrite de l éditeur est interdite, sauf dans les cas prévus par les articles 40 et 41 de la loi du 11 mars P&C France. Toutes les marques citées sont des marques déposées. Les vues et opinions présentées dans cette publication sont exprimées par les auteurs à titre personnel et sont sous leur entière et unique responsabilité. Toute opinion, conseil, autre renseignement ou contenu exprimés n engagent pas la responsabilité de Press & Communication. Abonnements Vous pouvez vous abonner gratuitement sur 4 IT-expert n 88 - novembre/décembre 2010

5 IT-expert n 88 - novembre/décembre 2010 Sommaire 6 Dossier Architecture de Sécurité - coopérer pour protéger efficacement son SI A travers une démarche de dialogue entre les différents services de la DSI et les utilisateurs métier, l auteur propose une évolution des pratiques de gestion du changement. Un cadre de coopération qui s élabore progressivement pour que chacun s implique dans une vision globale. Un article très concret! 14 Technique Les Appliances dans les Infrastructures SOA Des boîtes noires au cœur des applications? Les appliances SOA prennent surtout en main les fonctions techniques de l infrastructure. Paramétrables et alignées aux politiques de l entreprise, elles l emportent souvent sur une solution logicielle. Encore faut-il choisir en connaissance de cause. 19 Technique TOP5 des anti-patterns appliqués à l ESB À contre-courant des innombrables guides de bonnes pratiques, Claude-Emmanuel Drexler (responsable de l offre ESB chez Logica Business Consulting) distille avec humour et professionnalisme issus de son expérience de terrain. Instructif et éclairant! 24 Actualités Internationales Les informations marquantes d éditeurs, de marchés, d organisme de standardisation, de débats en cours et de tendances. 28 Comment ça marche? Les visions dynamiques de l Architecte d Entreprise En quoi l aspect «transformations» des SI et des organisations favorise-t-il une vision globale de l entreprise et comment cela contribue-t-il à une représentation compréhensible et utile des chaînes de valeur? Le point de vue éclairé d un spécialiste. 36 Quoi de neuf docteur? La gouvernance du patrimoine applicatif - optimisation de la qualité applicative Lætitia Bardoul, Senior Analyste pour le CXP, défriche concrètement le terrain de la gouvernance applicative. Une occasion d y voir plus clair dans ces concepts surutilisés, et de comprendre comment se positionnent les divers modules, ainsi que les éditeurs spécialisés. 41 Livres Expression des besoins pour le système d information d Yves Constantinidis et Moderniser son système d information de Sabine Bohnké. 42 Rubrique à brac Le Cloud Computing privé au service des métiers Les technologies et innovations du cloud computing peuvent aussi se décliner dans l infrastructure de l entreprise. Ainsi, la DSI passe du rôle de fournisseur de moyens à celui de fournisseur de services en proposant enfin le modèle «Self Service», aboutissant au catalogue de service personnalisé. IT-expert n 88 - novembre/décembre

6 Architecture de Sécurité Coopérer pour protéger efficacement son SI Pourquoi établir un mode de coopération plus mature entre la sécurité des SI, la DSI et les métiers? Tout simplement pour anticiper les besoins métiers, participer à l élaboration de propositions IT et concevoir une architecture de sécurité d entreprise efficace. L objectif ultime visant à préserver et à protéger ce patrimoine immatériel de l entreprise. Une démarche plutôt centrée sur la dynamique d évolution de l architecture de sécurité que sur un modèle générique utilisable pour toute entreprise. 6 IT-expert n 88 - novembre/décembre 2010

7 Dossier Un environnement en mutation permanente Le besoin croissant d échanges d informations fiables au sein de l entreprise et au-delà de ses frontières, la création de nouveaux espaces stratégiques et de «business models» reposant sur la collaboration entre partenaires et compétiteurs internationaux, la mutation vers une économie numérique mondiale autant de préoccupations qui ont transformé la sécurité de l information en enjeu stratégique majeur. Le lien est désormais direct entre les évolutions permanentes des entreprises, les systèmes d informations et la sécurité de l information. En effet la plupart des projets de transformation d entreprise impactent directement le système d information. Deux cas se présentent : soit la transformation de l entreprise a un impact sur le système d information existant peu évolutif. Dans ce cas, le système d information est identifié comme un des freins aux évolutions (fusion d entreprise, acquisition, séparation, filialisation ) ; soit le système d information sert de moteur à la transformation de l entreprise (lancement d un site E-commerce, usage du multicanal, lancement de nouveaux services clients ). Dans les deux cas, l anticipation et l adaptabilité du système d information restent essentiels. Ces changements génèrent ainsi de nouveaux défis pour la sécurité des systèmes d information, tant technologiques et réglementaires, qu organisationnels. De nombreuses évolutions ou innovations technologiques impactant déjà la sécurité des SI, parmi lesquelles : Le Cloud Computing : l arrivée de nouveaux modèles de consommation de services et d infrastructures informatiques nécessite de gérer différemment la sécurité des systèmes d information. En effet, si les différentes formes du Cloud Computing privé, public, IaaS, PaaS, SaaS impactent différemment la sécurité des SI, il semble cependant que les différents modèles vont coexister dans l entreprise. Charge aux acteurs de la sécurité de définir les principes, les guides et les règles d usage des composants et des données, pour garantir l interopérabilité et la sécurité de l information. L ouverture des SI : l idée consiste à identifier les limites de l approche périmétrique qui ne permet plus de garantir la fluidité des échanges et l agilité requise au SI tout en donnant une fausse impression de sécurité. Il s agit plus de redéfinir les frontières que de les supprimer. Or, redéfinir régulièrement les frontières est une œuvre de plus en plus collective, qui repose sur une vision systémique et architecturale du système d information. Les systèmes industriels : les composants informatiques utilisés au sein des systèmes industriels sont désormais basés sur les standards du marché informatique, avec leurs avantages (coûts, pérennité, compétence), mais également leurs règles et contraintes (rythme des versions, anomalies, vulnérabilités, menaces). Il s agit d un nouveau champ d action pour la sécurité des SI, qui nécessite d appréhender une fois encore la sécurité, avec une approche coopérative et architecturale des systèmes industriels. Les objets communicants : il s agit d anticiper les nouveaux usages d Internet et des objets (des téléphones jusqu aux puces communicantes) et de positionner la sécurité comme un facilitateur, afin d anticiper la sécurisation des données réparties, les interactions avec l existant et les contraintes réglementaires. Le Challenge vise donc à positionner efficacement la sécurité des SI sur le chemin de la transformation, mais également de construire au sein de l entreprise cette capacité de transformation. En effet, plus que de transformer et de sécuriser le SI, les entreprises ont besoin de construire de façon durable une capacité collective à se transformer. C est pourquoi certaines grandes entreprises et administrations mettent en place un cadre de coopération, avec pour objectif d organiser la dynamique d évolution du Système d Information. L architecture de la sécurité d entreprise en fait partie. Formaliser un cadre de travail pour l architecture de sécurité Comment mobiliser les énergies pour créer la dynamique d évolution? Cette démarche vise à permettre un dialogue équilibré entre les acteurs différents (métiers, utilisateurs, architectes, réalisateurs, exploitants et sécurité), à faire émerger des propositions, à prendre des décisions et à les exécuter par consentement, à conduire les évolutions d architecture. Autant de défis qui nécessitent de changer les pratiques de management des transformations. La clé pour concrétiser et inscrire ces intentions dans la durée est de mettre progressivement en place un cadre de coopération permettant à chacun de contribuer dans une vision globale, de capitaliser et de diffuser les règles au sein des projets. Les pratiques de la sécurité des SI et l architecture de sécurité d entreprise Quand on parle de sécurité des systèmes d information, on évoque plusieurs aspects : Le management de la sécurité de l information (politique de sécurité, gestion du risque), L architecture et l expertise des composants contribuant à la sécurité (IAM, PKI, Firewalls ), La sécurité opérationnelle (gestion quotidienne de la sécurité, exploitation de la sécurité). La sécurité opérationnelle consiste à mettre en œuvre les processus définis pour assurer la sécurité de l information. Par exemple, l organisation d audits, l attribution de droits, la configuration des firewalls ou l analyse régulière d indicateurs. Cette activité est en lien direct avec le management de la sécurité qui s assure que la sécurité opérationnelle est correctement exécutée. L alignement de la sécurité opérationnelle sur la gestion des risques de l entreprise est alors fondamental. IT-expert n 88 - novembre/décembre

8 Le management de la sécurité met en œuvre la gestion des risques visant à assurer que le niveau de sécurité reste en ligne avec la stratégie de l entreprise, et à initier les projets nécessaires. Il revient aussi au management de la sécurité de l information d assurer le suivi régulier des actions, et d élaborer les évolutions nécessaires. Les apports de l architecture s évaluent au regard de la complexité, de l impact de l existant, et du nombre de chantiers de transformation de l entreprise. Il est en effet souhaitable que la sécurité soit prise en compte à tous les niveaux de l architecture de l entreprise. Le moyen de s en assurer est d intégrer la sécurité comme un des éléments de la vision, des phases de conception, mais également d accompagner les projets par des moyens adhoc (mise à disposition de composants, de modèles, d expertises). L Architecture de Sécurité d Entreprise (ASE) assure la cohérence entre ces trois activités de la sécurité des SI et les projets de transformation de l entreprise. En effet, il ne s agit pas de proposer et réinventer une nouvelle méthode ou un énième modèle révolutionnaire, mais bien de mettre en place ou de renforcer un cadre d architecture proposant un ensemble d éléments et méthodes pour construire, représenter et analyser les systèmes de l entreprise. Un cadre de coopération d architecture de sécurité d entreprise propose trois composantes : 1. un référentiel d Architecture de Sécurité d Entreprise 2. le processus de pilotage de la transformation 3. le cadre de capacité de transformation Le référentiel d AE et sa déclinaison ASE Le référentiel regroupe les prescriptions d architecture, les composants réutilisables... Il couvre aussi bien la définition des prescriptions elles-mêmes que leurs modalités d évolution ou encore la manière de les communiquer et de les publier. En complément de la modélisation descriptive du SI, le référentiel ajoute les règles, les principes et les composants fonctionnels et techniques qui organisent la modularité et favorisent l assemblage et l intégration des sous-systèmes. La construction collaborative du référentiel passe par un équilibre entre des initiatives «centralisées» et un enrichissement de ce référentiel au fil des projets et des usages locaux. En s appuyant sur un référentiel commun, les sous-systèmes ainsi représentés sont assemblés pour donner une vision instantanée, à jour, et cohérente, du système d information et de sa sécurité. Le référentiel d AE s impose ainsi comme un outil de capitalisation, de communication et d échange entre les parties prenantes. Il facilite la compréhension des différents points de vue, l analyse de scénarii et des dépendances, le partage d information ; il permet l émergence de solutions dans la coopération et non dans l opposition. Il appartient aux architectes d en expliquer et d en faciliter l usage. Principes, Vision, Exigences d Architecture Phases préliminaires Vision d architecture Stratégie Métier - Stratégie Technique Moteurs - Acteurs Exigences - Hypothèses - Ecarts Architecture Business Motivation Organisation Fonction S É C U R I T É Architecture des systèmes d informations Données Application S É C U R I T É Architecture Technique Services de Plateformes Composants Techniques S É C U R I T É Opportunité, Solution, Planification Réalisation de l architecture Gouvernance de la réalisation Figure 1 : le référentiel d ASE 8 IT-expert n 88 - novembre/décembre 2010

9 Le processus de pilotage de la transformation Si la transformation de l entreprise passe par l alignement des projets locaux sur les objectifs locaux, elle doit également garantir la cohérence des projets par rapport aux principes d entreprise, dont la sécurité. Il est donc essentiel d identifier et de différencier le processus d évolution de la politique et du référentiel d entreprise, et le processus d alignement des projets unitaires, sur leurs objectifs propres dans le respect des règles d entreprise. Réussir la transformation Parmi les éléments essentiels, on retrouve le référentiel, les principes de gouvernance, mais également les compétences à renforcer et l organisation à mettre en place. Bâtir une capacité d architecture : volet compétence Structurer l organisation Processus Référentiel Développer et entretenir les compétences individuelles et collectives Rôles et Responsabilités Grille de Compétences Formation Cursus Parcours Déployer la transformation cible Référentiel Architecturer la transformation Evaluation Coaching Monitorat Projets de la transformation existant Gouvernance Gouverner la transformation Les points de vue Instruire l architecture Cadrer la transformation Figure 3 : cadre de capacité (source Arismore) L Architecture de Sécurité d Entreprise, s articule autour de la gestion des exigences, afin de capturer les besoins métiers, de diffuser les principes de sécurité de l entreprise, et de gérer de façon cohérente l ensemble. Figure 2 : processus de transformation ASE (Source Arismore) Le schéma ci-dessus présente le processus permettant d identifier les besoins et de définir une cible, une trajectoire, un plan de route et des moyens associés, d une part, et le processus d ancrage des projets, d autre part. Le cadre de capacité de transformation Au-delà des éléments techniques et opérationnels décrits dans les deux items précédents, l apport réside également dans sa dimension managériale et humaine : le cadre et sa capacité à se transformer. Ce cadre recense les actifs à mettre en place et à maîtriser pour faire de l architecture un levier de transformation et de sécurisation de l entreprise. Une exigence exprime ce qu un système devra être ou faire et les propriétés qu il devra avoir. L ingénierie des exigences est une activité essentielle pour la fourniture d un système (vue du fournisseur) et son acquisition (vue de l utilisateur ou du client). Elle permet de réduire les coûts et délais de réalisation tout en améliorant la qualité et la sécurité. En effet, une exigence définit ce qu un système (ou un produit ou un service) devra être ou devra faire (vue fonctionnelle) et les propriétés qu il devra avoir (vue non fonctionnelle) pour répondre aux buts fixés par les acteurs. Une exigence exprimée ne sera pas nécessairement satisfaite. Mais cela permettra justement de tracer la nonsatisfaction, ce qui réduit l implicite à l origine de nombreux conflits et blocages. L ingénierie des exigences est une activité qui s applique tout au long du cycle de vie d un produit, d un service ou d un système. Elle ne se limite pas aux phases initiales d analyse et de conception, même si l essentiel de l effort peut être réalisé lors de ces phases. IT-expert n 88 - novembre/décembre

10 Ainsi l ingénierie des exigences est l ensemble des activités consistant à : collecter et expliciter les besoins, attentes, contraintes et interfaces des parties prenantes pour toutes les phases du cycle de vie du système ; analyser et valider les exigences ; établir des scénarii pour satisfaire au mieux les exigences en fonction des contraintes ; gérer le suivi (changement, suppression, création) et la traçabilité (date de changement, auteur du changement ) des exigences ; assurer les arbitrages entre les exigences en fonction des contraintes ou pour résoudre des contradictions entre exigences ; valider la cohérence entre le système réalisé et les exigences. Une exigence ne contient pas d information concernant le design ou la conception du système. Elle exprime ce que le système devra être et non pas comment il devra être réalisé. Pour une même exigence, plusieurs solutions de design et conception sont possibles. Bien utilisée, cette démarche devient le moteur pour construire le cadre de l architecture de sécurité d entreprise. Comment mettre en place un cadre de coopération? La mise en place des pratiques d architecture de sécurité d entreprise s appuie sur une structuration des activités opérationnelles d architecture sous la forme de six thèmes. La trajectoire : contribution à la trajectoire de transformation d un Système d Informations ou d un domaine. Il s agit de construire une trajectoire d évolution basée sur une analyse des écarts entre une cible et un existant, suivie de la planification des projets alignés sur les exigences. Le référentiel d architecture et de sécurité : construire et capitaliser sur un cadre contenant les prescriptions d architecture, les principes de sécurité, la modélisation ou cartographie du SI. La gouvernance : enrichir les processus et les instances contributives permettant de gouverner la mise en œuvre de la trajectoire et l alignement des projets. Les projets : communiquer auprès des métiers et accompagner les projets au bon usage du référentiel avec une démarche de bout en bout depuis les phases avant-projet (opportunité, faisabilité) jusqu au déploiement. Le cadre de capacité : renforcer les capacités de l entreprise en agissant sur les pratiques, l organisation, les compétences, la conduite du changement et la communication. La Gestion des identités et des accès, un cas concret L un des blocs types de sécurité s inscrivant globalement dans une Architecture de Sécurité d Entreprise est la gestion des identités et des accès. En effet, une telle infrastructure permet de répondre à divers objectifs : réduire le niveau de risque récurrent dans les entreprises concernant la gestion des identités ; s inscrire dans les bonnes pratiques de la sécurité telles que définies dans la famille ISO 2700x ; concourir au respect des contraintes réglementaires métiers ou financières ; proposer un service transverse de sécurité concourant à une ouverture sécurisée du SI vers l extérieur ; prendre en compte les nouvelles architectures liées au Cloud Computing et à la mobilité ; offrir un catalogue de services permettant d offrir de nouveaux services métiers tout en répondant à la problématique du «Time to Market» ; apporter un plus grand confort aux utilisateurs finaux ; améliorer la qualité des processus supports ; bénéficier d un retour sur investissement au regard de la couverture du SI (applications et infrastructures) et des populations utilisatrices. Une infrastructure globale de gestion des identités fournit différents services à différentes populations : employés, partenaires, fournisseurs, clients (cf. figure 4 page suivante) L infrastructure de gestion d identité permet de rendre le SI plus performant, plus agile et plus sécurisé tout en répondant à des contraintes réglementaires (conformité). Toutefois un projet de gestion des identités et des accès réunit diverses parties prenantes (ressources humaines, services généraux, métiers, SI, sécurité ) avec différents points de vue et qui viseront chacun des bénéfices spécifiques. Répondre à ces usages et aux besoins de ces différentes populations passe par la mise en œuvre de processus optimisés et outillés : gestion du cycle de vie de l identité, gestion du cycle de vie des rôles, gestion des ressources, gestion du risque. La mise en œuvre de ces processus nécessite la définition de services transverses. 10 IT-expert n 88 - novembre/décembre 2010

11 Dossier gestion de l identité : réconciliation avec des sources autoritaires, processus d approbation, self-services provisioning : synchronisation avec les bases utilisateurs dans le SI ; gestion des rôles : lien entre l utilisateur et les ressources autorisées dans le SI. En effet, le rôle doit être géré au même titre que les autres objets ; en effet, le rôle peut être impacté par la vie propre des applications, la transformation du métier de l entreprise contrôle d accès : authentifier et autoriser l utilisateur pour une ressource ; fédération d identités : partager des données d identité entre des organisations indépendantes les unes des autres (cercles de confiance) ; audit : capacité à tracer les actions réalisées dans les services précédents et à présenter un reporting en fonction du profil de consultation. Pour que ces services soient fonctionnels, il est nécessaire de s appuyer sur différents référentiels (identités, habilitations, ressources ) et différents principes (architecture et sécurité). La réalisation d un tel projet ne peut se faire que dans le cadre d une démarche collaborative réunissant les différentes parties prenantes afin de définir : les exigences liées au projet ; les besoins auxquels il doit répondre en fonction des populations utilisatrices ; les modèles d architecture permettant de répondre à différents cas d usage afin de construire un catalogue de services ; la planification dans le temps de la mise en œuvre au regard des services envisagés et au regard de la gouvernance du SI (mise en œuvre parallèle de programmes métiers) ; la capitalisation des savoir-faire. Le cadre de collaboration et le projet de gestion des identités et des accès se complètent avantageusement. En effet, les services de gestion des identités et des accès enrichissent l architecture de sécurité d entreprise et, de ce fait, le référentiel. Quant au projet, il profite de la modélisation, du référentiel, du processus d évolution, et du processus d ancrage pour le raccordement des applications, l ingénierie des exigences ( ) proposé par le cadre de coopération. Les initiatives de l Open Group et du SABSA Institute L Open Group, a lancé plusieurs initiatives pour construire un cadre de coopération pour la sécurité, à travers plusieurs forums ; L architecture Forum Le Security Forum Le Jericho Forum TOGAF (The Open Group Architecture Framework) est un cadre d architecture d entreprise collaboratif permettant le partage de points de vue entre les parties prenantes de l entreprise, pour agir dans l intérêt collectif. Usage et parties prenantes Principes Acteurs du SI Utilisateur RH Métier RSSI Performance Conformité Sécurité Sécurité Référentiels Informations Processus Gérer le cycle de vie des utilisateurs et des rôles Gérer les ressources Gérer le risque SI Personnes Identités Processus Architecture Contrôle d accès Gestion des identités Fédération Audit Provisioning Gérer les rôles Figure 4 : la Gestion des Identités et des Accès (Source Arismore) IT-expert n 88 - novembre/décembre

12 COA (Collaboration Oriented Architecture) du Jericho Forum apporte un cadre de travail pour l ouverture des Systèmes d Information, avec une vision besoin des entreprises. Le SABSA (Sherwood Applied Business Security Architecture) du SABSA Institute est un cadre d architecture de sécurité d entreprise qui, au-delà des modèles et de la gestion du risque, introduit une méthode intéressante pour capturer les exigences (Business Attribute Profile). A la demande des partenaires de l Open Group, un groupe composé de membre de l Open Group (Security Forum et Architecture forum) et du SABSA Institute, travaille sur des initiatives de rapprochement comme l utilisation de pratiques communes pour la gestion des exigences et la mise à disposition de composants d architecture (vues, building blocks, artefacts). Pour les entreprises françaises, il est possible d enrichir progressivement leurs propres cadres des bonnes pratiques présentées en cohérence avec le système de gestion de la sécurité de l information proposé en se référant aux normes ISO 2700x. En effet, l accompagnement des projets de transformation de l entreprise et la contribution aux initiatives nationales et internationales sont d excellents moyens de valoriser et professionnaliser les métiers de la sécurité des SI. n A noter L Open Group a également créé un nouveau forum Trusted Technology Forum pour travailler sur la gestion de la chaîne d approvisionnement afin de garantir la sécurité des matériels et des logiciels achetés par les gouvernements et les grandes entreprises commerciales. Le cadre (Technology Provider Framework) ainsi initié fédère les bonnes pratiques à destination des fournisseurs afin de les aider à garantir la sécurité de leurs produits. Gilles Castéran, Directeur Associé d Arismore Arismore est une société innovante en conseil et intégration qui accompagne la transformation et la sécurisation des systèmes d information des grandes entreprises et des administrations. Avec un chiffre d affaires de 11 millions, Arismore est devenu le spécialiste en France de l Architecture d Entreprise et de la Gestion des accès et des identités. Site web : 12 IT-expert n 88 - novembre/décembre 2010

13 IDC vous donne rendez-vous mercredi 19 janvier 2011 (9h 14h) CONFERENCE IDC : OPTIMISER SA STRATEGIE DE SOURCING Insourcing, outsourcing, nearshore, offshore, Cloud Computing : comment tirer le maximum des différents modèles? Le DSI doit prendre en considération les objectifs stratégiques de l entreprise mais aussi les objectifs tactiques des différentes entités métiers. La réactivité de la DSI, couplée à la qualité de services rendus aux directions métiers sont deux critères essentiels aujourd hui. La question qui se pose alors est bien : Quelle stratégie de sourcing est la mieux adaptée à mon entreprise? La question est complexe et n appelle pas une réponse unique, d autant plus que les modèles à disposition des DSI sont toujours plus nombreux : tout réaliser en interne?, insourcing? outsourcing?, onshore? nearshore?, offshore?, Cloud Computing? Tous ces modèles sont ou seront présents dans les entreprises et il devient très important de faire les bons choix de modèles de delivery pour les bonnes «briques» du système d information. De plus, il faut être en mesure de d optimiser l ensemble sans créer de silo ou de point de friction. La politique de Sourcing Au programme : Mesurer les enjeux et la création de valeur pour l entreprise : réduire les coûts, gagner en flexibilité et libérer des ressources pour investir dans de nouveaux projets ou de nouveaux modèle économiques Conférence organisée par IDC Différents modèles et solutions de global sourcing Définir une politique de sourcing adaptée et adaptable à la transformation de l entreprise et garante de l optimisation de l infrastructure et des applications Le Cloud Computing Gagner une longueur d avance vers l étape ultime de l externalisation? IDC, cabinet leader de conseil, et d études dans les technologies de l information en partenariat avec Avec le retour d expérience de : Bertrand ETENEAU DSI Faurecia Yann BEYNoN DSI RoCHE Gael DoMINIQUE Direction des achats Groupe ToTAL Stéphane CoRDIER DSI Alliance Healthcare France Participez à la conférence IDC Stratégies de Sourcing le 19 janvier 2011, à Paris pour : dresser le bilan et faire le point sur les différents projets mis en place à ce jour. analyser ensemble quelles sont les bonnes pratiques, quels sont les leviers opérationnels et technologiques à votre disposition. faire les bons choix de modèles de delivery pour les bonnes «briques» du système d information. PROGRAMME DETAILLE ET INSCRIPTION GRATUITE : code invitation «ITX» ou contacter Edith Tricheux [email protected] - tel. :

14 Les Appliances dans les Infrastructures SOA 14 IT-expert n 88 - novembre/décembre 2010

15 Technique Infrastructures SOA et trafic XML La consommation grandissante des flux XML dans les infrastructures informatiques ne permet plus d envisager la solution logicielle comme étant l unique possibilité offerte pour traiter ce type de flux. En effet, les traitements sur les flux XML sont de plus en plus complexes et nombreux. Ils nécessitent des capacités de mémoire et de traitements importants, pour réaliser des fonctionnalités purement techniques et qui n apportent aucune valeur ajoutée aux applications métiers des entreprises. Des traitements variés liés aux contenus XML Il s agit principalement des traitements tels que : Transformation, adaptation de contenu Extraction, filtrage de données Validation des messages XML Chiffrement et déchiffrement de données XML Signature digitale et vérification de signature dans des documents XML Cette consommation de flux XML est liée en partie à l adoption désormais constatée des services Web au sein de l informatique de nombreuses entreprises. Concernant les flux de type services Web SOAP (Simple Object Access Protocol), les traitements XML concernent également l utilisation des standards Web-Services aboutis, quels qu ils soient : WS-Reliable Messaging WS-Addressing WS-Trust WS-Security WS-Policy Les applicatifs doivent réaliser des traitements visant à garantir la sécurité des applications et programmes qui consomment les contenus XML. En effet, les menaces XML sont relativement simples à créer et pénalisent lourdement les victimes de telles attaques. Parmi les plus classiques, on notera par exemple : Les dénis de service XML ou «XDoS» (XML Denial of Service) L accès non autorisé à des services La compromission de systèmes informatiques (XML Virus) Les attaques visant la confidentialité et l intégrité des données Outre ces contrôles sur les contenus, les applicatifs doivent réaliser d autres traitements techniques, distincts de toute logique métier. On notera par exemple : La gestion des habilitations pour l accès aux services de l infrastructure SOA, Les ruptures protocolaires parfois nécessaires, Le routage technique ou fonctionnel de l information, L exposition et le management des services, permettant par exemple de lisser le trafic ou le rejeter si le seuil d accès vers un service est dépassé (de manière générale ou pour un utilisateur en particulier). Le besoin de performance et de sécurité Les appliances (SOA Service Oriented Architecture) ont pour principal objectif de supporter des fonctions techniques clés de l infrastructure SOA de manière à garantir la pérennité des applications et des fournisseurs de services. Parce que les contrôles et traitements précités doivent être effectués en minimisant l impact sur les performances de l infrastructure SOA et en garantissant sa sécurité, une solution logicielle ne peut pas être envisagée à la différence d une approche par «appliance». Les appliances consistent en des équipements de type «réseau», dédiés à des traitements applicatifs plus ou moins étoffés selon les gammes proposées par les principaux éditeurs du marché. Les appliances SOA incarnent une déclinaison particulière de cette offre dans le sens où elles sont capables d effectuer des traitements et contrôles spécifiques aux services Web sur des trafics tels que SOAP, XML/RPC ou REST (Representational State Transfer). Des appliances à caractère technique Une appliance SOA est constituée d un équipement matériel qui embarque un microcode (ou «firmware»), élément indispensable et optimisé, qui porte l ensemble des possibilités de traitement offert par l appliance SOA considéré. Cette approche simplifie considérablement l installation, le déploiement et l évolution de l infrastructure SOA basée sur ce type de composant. En outre, elle opère une séparation claire entre les fonctions techniques et métiers, étant précisé que les appliances SOA n ont pas pour vocation de supporter quelque logique métier que ce soit, mais de prendre en charge des fonctionnalités exclusivement techniques. De plus, une appliance est un système configurable et non pas programmable ; il offre dans la plupart des cas des interfaces multiples (commande en ligne et interface graphique par exemple) permettant d implémenter les configurations requises. Ce mode d implémentation masque la complexité des spécifications et protocoles, en synthétisant les informations requises. La fourniture d interfaces de configuration diverses permet d adresser un large public : opérateurs réseau : installation physique et paramétrage réseau de l appliance, responsables sécurité : configuration des politiques de sécurité (contrôle d accès, menaces XML, protection des serveurs d arrière-plan ), architectes et développeurs : définition et implémentation des services. Par rapport aux menaces XML, il existe deux approches concernant les appliances SOA : 1. l approche positive consiste à rejeter, par défaut, toutes les attaques existantes. Il est cependant possible de diminuer le niveau des contrôles effectués. IT-expert n 88 - novembre/décembre

16 2. l approche négative consiste à n effectuer aucun contrôle de sécurité. Ces contrôles sont configurés au cas par cas, selon les besoins de sécurité. Un retour sur investissement très avantageux Une autre caractéristique intéressante des appliances SOA, leur excellent retour sur investissement. Les différents coûts à envisager pour effectuer une comparaison entre une appliance et une solution logicielle équivalente sont les suivants : coûts de l infrastructure opérationnelle complète ; coûts des développements d applications et de maintenance de la solution ; coûts d acquisition des produits ; charges de maintenance des produits ; coûts d installation et de déploiement. L ensemble de ces coûts est bien plus important avec une solution logicielle, car celle-ci nécessite plus de ressources (humaines, logicielles et matériels) dans l ensemble des phases de réalisation d un projet SOA. Où positionner ces appliances? Les appliances SOA se positionnent principalement en frontal des fournisseurs de services et des applicatifs de manière plus générale. Ils sont alors capables de : garantir la sécurité interne ; s intégrer avec des applicatifs de type legacy, via des connecteurs dédiés : dans ce cas, l appliance SOA doit pouvoir effectuer des transformations sur des contenus autres que XML. Autre positionnement possible : au sein de la DMZ (zone démilitarisée). Dans la mesure où ils sont capables de satisfaire à des niveaux de certification ou des critères de sécurité permettant leur utilisation dans cette zone particulière de l infrastructure d une entreprise. La rupture protocolaire opérée en DMZ par l appliance SOA est une garantie nécessaire de sécurité. Le fait d embarquer un microcode dans l appliance renforce également la sécurité dans la mesure où cette approche empêche tout développement de script ou ajout de modules supplémentaires à la solution qui pourrait impliquer de potentielles failles de sécurité. Ainsi, une appliance SOA embarque un microcode offrant au final une solution configurable complète, à la différence d une solution logicielle basée sur un serveur, sur laquelle un développement spécifique doit être implémenté et maintenu. DMZ Appliance SOA Web-Services Consommateurs Internes D une manière générale, une appliance SOA est gérée comme un équipement réseau traditionnel à l inverse d une solution basée sur plusieurs serveurs dont les coûts de gestion et de maintenance sont sans commune mesure. Web-Services Consommateurs Externes SOAP/HTTP(S) IP Firewall Appliance SOA IP Firewall SOAP/HTTP(S) Web-Services Fournisseurs Une intégration simplifiée à l infrastructure SOA L intégration des appliances dans l infrastructure SOA est facilitée, car elle se base sur des standards et spécifications. En effet, si les composants logiciels avec lesquels doit s intégrer l appliance utilisent des APIs ouvertes (basées par exemple sur SOAP ou REST), ou des protocoles d échange standardisés, alors l intégration est facilitée et s en trouve considérablement accélérée. Voici quelques exemples : les principaux registres et référentiels de services offrent, en plus d UDDI, des interfaces SOAP/REST permettant la récupération de métadonnées relatives aux services, à partir d une appliance SOA ; les scanners antivirus offrent une intégration possible via ICAP (Internet Content Adaptation Protocol), permettant à une appliance SOA de transmettre les attachements des messages SOAP et de rejeter tout contenu infecté par un virus. Un tel positionnement en DMZ est envisagé lorsqu une appliance SOA est utilisée pour exposer des services (on parle également de «virtualisation» des services) à des partenaires externes à l entreprise. Dans ce cas, elle est utilisée pour détecter et contrer les éventuelles attaques XML, mais également pour contrôler les accès aux différents services via des politiques de sécurité spécifiques. Ces politiques se basent sur des composants externes à l appliance (tels que des annuaires LDAP par exemple) afin de renforcer des contrôles d authentification et d autorisation vis-à-vis des services fournis. On parle alors de passerelle de sécurité externe (ou interne) ou encore de point de passage unique du trafic des services Web. En fonction des appliances SOA, il est possible de les interfacer avec une solution de gouvernance et de gestion du cycle de vie des services (registre de services) afin d alimenter les services de virtualisation à l aide des contrats d interface des fournisseurs de services. 16 IT-expert n 88 - novembre/décembre 2010

17 Technique La possibilité d intégration avec les registres et référentiels de service est un point déterminant dans le choix d une appliance SOA. Un cadre normalisé et standardisé en zone SOA L un des principaux intérêts des appliances SOA est qu elles fournissent un cadre normalisé pour le traitement des flux de type Web-Services. Le point de passage unique qu elles constituent rend impossible le transit de flux qui ne respectent pas strictement les politiques de contrôle configurées sur ces solutions. Des échanges B2B fluides et sous haute sécurité Le RSSI d une société décide que tous les flux Web- Services en provenance de partenaires externes doivent : 1. utiliser le protocole HTTPS en authentification mutuelle, ce qui permet d identifier l application consommatrice du service, 2. utiliser un jeton de sécurité de type «UserName Token», permettant l identification des utilisateurs et le contrôle d accès aux services, et respectant la version 1.1 de la spécification WS-Security, 3. transmettre un flux valide, c est-à-dire qui respecte strictement le contrat d interface établi lors de la conception du service. Un partenaire externe à l entreprise et souhaitant consommer un service devra donc satisfaire à l ensemble des exigences, traduites sous forme de configuration au niveau de l appliance. Si une seule des conditions précitées n est pas respectée, alors l appliance SOA rejettera la requête du consommateur sans que cela n ait d impact sur le fournisseur du service qui n a à aucun moment été sollicité. Cette normalisation permet également aux entreprises d exposer de nouveaux services internes de manière optimisée. En effet, les responsables de l infrastructure SOA sont en mesure d exprimer des règles simples aux fournisseurs de services internes (équipes de développement) et d établir en quelque sorte les prérequis indispensables pour l exposition d un nouveau service sécurisé. Par exemple, l équipe d infrastructure SOA peut exiger que le contrat d interface (fichier WSDL du service) soit conforme avec la spécification «WS-Interoperability Basic Profile 1.0/1.1». Vis-à-vis des consommateurs du service, elle peut imposer une limite d utilisation du service par utilisateur, par consommateur ou commune à l ensemble des consommateurs du service. Les appliances SOA permettent évidemment d effectuer les contrôles de sécurité internes à l instar de ceux effectués pour les partenaires externes (détection et rejet des menaces, contrôle d accès, filtrage de données entrantes ou sortantes ) sachant que les attaques XML sont encore principalement exécutées par des utilisateurs internes aux entreprises. Monitoring de l infrastructure et des appliances SOA Les possibilités de monitoring offertes par SNMP permettent la supervision des appliances SOA et la récupération de métriques techniques diverses : usage CPU, consommation mémoire, nombre de connexions Le monitoring des services (Web- Services, services REST et XML) est également possible en utilisant des standards tels que WS-Management ou WS- Distributed Management, l idéal étant de pouvoir influer sur le registre des services à partir de la solution de monitoring, en fonction des données supervisées sur les appliances SOA. Ainsi, un consommateur peut être autorisé à consommer un service n fois par semaine. Si ce seuil est dépassé, il peut être nécessaire de fournir un service équivalent à ce consommateur, mais en mode «dégradé» (les informations retournées par le service pourraient dans ce cas être moins pertinentes). Si on considère les différentes briques de l infrastructure SOA que sont : l appliance SOA, le registre de gouvernance des services, la solution de monitoring des services ; Il est alors possible de mettre en place une solution à partir de laquelle la brique de monitoring sera alertée par l appliance d un dépassement de seuil, ce qui lui permettra de modifier la destination du service - pour le consommateur spécifique - au niveau du référentiel des services. L appliance SOA sera alors en mesure de router le consommateur vers le service «dégradé», sans intervention d un opérateur sur la solution de registre et sans modification ni du consommateur ni de la configuration de l appliance SOA. Web-Services Consommateurs Registre SOA SOAP/HTTP(S) Appliance SOA Monitoring Web-Services SOAP/HTTP(S) Web-Services Fournisseurs Au niveau de la solution de monitoring, l idéal est de pouvoir superviser l ensemble des intervenants : appliances et services, de manière à bénéficier d une vision globale de l infrastructure SOA au run-time. IT-expert n 88 - novembre/décembre

18 Appliance SOA et Bus de Services d Entreprise (ESB) Transformation, sécurité, routage dynamique de l information, management des services, rupture de protocoles, traçabilité des échanges : les principales fonctionnalités des ESB sont supportées par les appliances SOA. Le positionnement d une appliance SOA comme ESB peut être envisagé : si l appliance satisfait totalement aux besoins de connectivité exprimés ; si l appliance satisfait en partie aux besoins de connectivité exprimés, mais aussi si des interfaces standardisées de type Web-Services, XML/RPC, REST peuvent être implémentés sur les applications cibles, pour lesquels la connectivité n est pas assurée par l appliance ; si les besoins d orchestration au niveau des médiations du bus sont inexistants ou «légers» ; si les besoins en termes de performance et de sécurité sont importants : nombre de transactions élevé, nécessité de contrôler les flux, opérations cryptographiques Médiations exposées Appliance SOA Consommateurs Réseau Services Appliance SOA Le bus de service peut être accessible en externe à travers une appliance positionnée en DMZ, qui expose les services aux utilisateurs externes et assure les contrôles de sécurité nécessaires. Autre utilisation possible pour les appliances SOA : les interfacer en frontal d un ESB logiciel existant. Toutes les requêtes à destination de l ESB transitent alors par l appliance qui assure la sécurité de l infrastructure : à minima cela concerne la détection des attaques et la validation des messages. Il est également possible de déléguer à l appliance SOA le traitement des médiations qui ne nécessitent pas d orchestration (ou une orchestration légère) de manière à «soulager» l ESB logiciel de ces traitements. L appliance SOA assure également la protection de l ESB en limitant, si besoin, le nombre de transactions sur le bus. IP Firewall DMZ Appliance SOA IP Firewall Internet Consommateurs SOAP/XML/REST Appliance SOA SOAP/XML/REST SOAP/XML/REST Monitoring Services ESB Vers le «tout-appliance»? Les solutions à base d appliance se développent chez de nombreux éditeurs et intègrent de plus en plus de fonctionnalités techniques. L idée consiste à promouvoir des solutions permettant de centraliser les fonctions clés des infrastructures informatiques. Parmi les solutions les plus récentes, notons les appliances assurant la sécurisation des échanges B2B (Business to Business), celles assurant la connectivité entre des applications d une entreprise (dites «on-premise») et les applications présentes sur un Cloud, dans des domaines comme le CRM (Customer Relationship Management) ou encore celles permettant de gérer du cache applicatif. Le dénominateur commun de toutes ces appliances est qu elles n embarquent pas de logique métier et sont conçues pour effectuer des traitements spécifiques de manière optimisée et sécurisée. Il paraît cependant évident que les fonctions et applications métiers d une infrastructure informatique ne sont pas candidates pour être portées par une offre de type appliance, à une époque où l évolution de l informatique est de proposer une virtualisation de ces dernières intégrables et provisionnées dans un Cloud. n Joel Gauci, Certified IT Specialist Client Technical Professional chez IBM Software Group Services 18 IT-expert n 88 - novembre/décembre 2010

19 Technique TOP5 des anti-patterns appliqués à l ESB Appréhender de nouveaux concepts et s assurer de la bonne direction des projets informatiques nécessitent au préalable un arrêt sur ce qu on désigne couramment comme les «bonnes pratiques». Celles-ci sont généralement issues de la longue tradition des prédicateurs de nos temps, les «leads architects», respectables par leurs contributions à la discipline d ingénierie du logiciel. Aussi est-il commun de vérifier auprès de nos équipes, si celle-ci ont été bercées par des patterns du «GoF», de Martin Fowler, Jacobson ou plus récemment de Thomas Erl. IT-expert n 88 - novembre/décembre

20 Aujourd hui, ne pas disposer de connaissance des grands principes, et ne pas l exiger de ces équipes d architectes constitue une véritable prise de risque. Il est salutaire de prendre le temps de considérer, à la lumière des précédentes expériences, ce qui a été mal interprété des différents enseignements, ce qui n a pas fonctionné, puis de constater sans fard «tout le mal que l on ne souhaitait pas faire». Sous le vocable ESB se cachent 2 concepts différents : Le produit, offre logicielle évolution des EAI avec un outillage Web services et MOM. Le pattern d architecture, établissant une couche d intermédiation au sein du SI et endossant le rôle de fournisseur de service. L ESB expose alors des services sur la base d applications existantes via l utilisation de connecteurs («enablement»). Dans une démarche SOA, les concepts de «Médiation» et d «Exposition» font corps afin de fournir au reste du SI les services gages de stabilité et d évolutivité. Cause Tentative de rationalisation des services exposés au sein du SI sans prendre en compte les cas d usages métiers. Peur de l anti-pattern «Tout est Service». Démarche SOA portée isolément par l IT. Effet Les effets négatifs concernent la complexité fonctionnelle portée par ces services, qui répondent à de nombreux cas fonctionnels (tous les langages d implémentation ne sont pas aussi élégants que les prédicats Prolog pour adresser les clauses multiples ) ou bien une signature de service à tiroir, permettant la saisie de paramètres d entrée à géométrie variable. La gouvernance d un tel service s avère des plus délicates, puisqu il adresse de nombreuses problématiques, et donc en servant un dessein aussi large, est susceptible de subir de nombreuses évolutions. Nous risquons alors de produire de multiples versions, qui n intéressent qu un nombre limité de consommateurs, voire de multiplier les interfaces pour un même service, faisant alors porter l adaptation fonctionnelle par l ESB. Puisque l on aborde très souvent les bonnes pratiques, pourquoi ne pas se pencher sur quelques mauvaises pratiques communément recensées autour de la mise en place d un ESB? Anti-Pattern #1 Le Macro Service Description Suite à la mise en place d une méthodologie d identification de service, il peut arriver que le message initial de «rationalisation des services du SI» soit mal interprété, aboutissant à une situation opposée à celle recherchée ; une tentative de rationalisation du nombre d interfaces exposées pour un domaine fonctionnel, en fournissant des services de forte granularité. Nous tombons alors dans l excès inverse, à savoir : la fourniture d un nombre limité de services, qui répondent à un périmètre fonctionnel trop large. Exposition de Service Application Source Interfaces exposées Interfaces consommées Figure 2 : mauvais rôle fonctionnel endossé par l ESB Adaptation Fonctionnelle (filtrage, transformation ) Un corollaire, qui va généralement de pair avec les éléments décrits précédemment concerne les performances d un tel service. Il n est en effet pas rare de le voir remonter une grappe d objet d une profondeur importante afin de fournir à ces nombreux consommateurs toute l étendue des informations qu ils sollicitent. Applications Composites Portail Externe Interactions Utilisateurs et B2B Applications Composites Portail Interne & Applications Partenaires B2B Integration Référentiel de Sécurité Infrastructures transverses Registre et Référentiel SOA Médiation de Services Fournisseur/ Consommateur Business Process Management Moteur d exécution Exposition de Service (Enablement) Exposition de Service Moteur d exécution Business Database Domaine Métier 1 Application ERP Legacy Domaine Métier 2 Business Database Fonctions portées par un ESB Figure 1 : architecture logique simplifiée d un socle SOA 20 IT-expert n 88 - novembre/décembre 2010

21 Technique Solution Généralement, celle-ci est à rechercher du côté des cas d usages auquel doit répondre ce service (s il est de niveau Tache) ou bien sur l identification précise de la classe métier/catégorie qu il manipule (s il s agit d un service de type Entité). L objectif est de mieux délimiter le service offert, en proposant un nouveau découpage, permettant ainsi de séparer les populations consommatrices et ainsi, d être plus en phase avec les besoins. Si le service est découpé plus fin, le risque de remonter l intégralité des informations du domaine fonctionnel à chaque appel est plus limité. La solution est donc plutôt à rechercher sur la granularité du service à exposer, plutôt que sur une adaptation fonctionnelle portée par les capacités de l ESB. Anti-Pattern #2 Tout est service ou la SOA optimiste Description Il est commun dans une démarche SOA de tomber dans une exposition systématique en services Web, notamment en ce qui concerne les éléments du patrimoine applicatif existant. Il est bien de la prérogative de l ESB de porter cette fonctionnalité d exposition ; pour autant l exposition systématique sur un ESB de même typologie de services pose à la fois un problème de gouvernance ainsi que de performance, le protocole SOAP sur HTTP étant bavard. La mise en œuvre d une architecture SOA est alors communément confondue avec une démarche Web Service qui vise à remplacer les API ou les appels de procédure distante par l usage d un seul et unique protocole. Cause Leitmotiv souvent entendu «Nous avions déjà une démarche Service, il n y a plus qu à les exposer en Web services». Effet Cette déviation de la démarche apparait maladroitement comme une solution de rationalisation des interfaces applicatives. Pour autant, dans certains cas, la couche d exposition en Web Service n est pas forcément portée par une brique applicative performante et dégrade peu à peu le niveau de service du SI. Lorsque cet anti-pattern intervient dans un environnement possédant un ESB de type logiciel et non de type «Appliance», le goulet d étranglement n en est que plus évident. Par ailleurs, l ESB devient dans cette vision le nouveau «Single Point Of Failure» du SI. Certains détracteurs mentionneront que c est souvent le cas, puisqu il constitue le point d acquisition de l interface des services. Cependant, le risque est particulièrement renforcé avec une démarche ou tout service technique ou purement applicatif serait exposé. Solution Ce biais entraine une forte complexité de gouvernance des services. Dans une démarche SOA, il faut conserver comme objectif de construire et d exposer des services qui ont une véritable plus value métier. Le décommissionnement des protocoles existants, voire natifs, ne doit pas intervenir de manière systématique, mais doit toujours être motivé par un besoin avéré d interopérabilité. La question doit également se poser dans le cadre de la démarche d identification des services : un service dit «Utilitaire» (1), bien qu identifié en terme de service SOA, porte une implémentation qui ne systématise pas l usage d un web service. Cet anti-pattern s avère d autant plus nocif à moyen terme pour le SI lorsque la démarche d exposition du SI en service n est pas adossée à un référentiel de service (qui n est pas un simple annuaire UDDI!). Taux de réutilisation croissant Service Processus Service Tâche Service Entité Figure 3 : typologie de service d une démarche SOA Anti-Pattern #3 Réplication de données Service Utilitaire Description Un des usages souvent rencontré, porté par l ESB, correspond à la propagation d information au sein du SI plutôt que leur mise à disposition. Cet usage est toujours lié à l utilisation d un ESB en tant qu EAI en pérennisant les architectures de ce type. Pour autant, ce mode de fonctionnement n est pas totalement proscrit lorsqu il concerne des informations de type «évènement» permettant de déclencher des processus transverses. Le point d attention concerne donc bien ici la typologie des informations mises à disposition. Dans certaines organisations, souvent portées par des progiciels qui ont l habitude de fonctionner dans leur propre écosystème sans s interfacer avec le reste du SI, la démarche d adressage de service n est pas naturelle. Cause Une vision en Silos de données, souvent issus d une vision purement «Progicielle» ou applicative du système d information. Effet Les effets négatifs sont assez nombreux et pérennisent ce qui serait à proscrire : la multiplication des référentiels de données d entreprise. Sans évoquer la nécessité d une réelle gouvernance de la donnée, de la désignation du maître de celle-ci et de son cycle de vie, il est important dans une démarche SOA de porter une attention particulière à ne pas propager des informations qui ont plutôt vocation à être exposées. 1) Service proposant des fonctionnalités d administration, de supervision fonctionnelle ou technique, de gestion de l infrastructure. Voir Référentiel méthodologique GO-ON pour plus d information sur la démarche SOA préconisée. IT-expert n 88 - novembre/décembre

22 La désynchronisation des données est un risque fort, directement lié à la mise en place de cet anti-pattern. La duplication des traitements voire, la multiplication des services en est un autre. En effet, rien n empêche d offrir des services sur ces données une fois celles-ci intégrées dans son propre référentiel. Cette divergence est généralement portée par l interaction avec des progiciels d entreprise monolithiques qui ont pour (mauvaise) habitude de chercher à acquérir toutes les données qu ils manipulent, dupliquant ainsi les traitements. Solution En allant au bout de cette recommandation, il est de la responsabilité du producteur de la donnée d offrir un service de mise à disposition de ces informations ou du traitement recherché. Ce traitement peut être délégué à un tiers pour des raisons de dénormalisation technique, mais celui-ci constitue alors le point d acquisition unique de l information (et non du flux de donnée). On pressent bien évidemment que cela ne va pas sans heurts ni tracas, et contrarie les porteurs du progiciel et le producteur de la donnée, qui dans le cas de cet anti-pattern avait juste à propager la donnée sans se préoccuper des besoins des consommateurs, ou du devenir de celle-ci. Anti-Pattern #4 La multiprise Description En digne héritier des EAI en terme d offre produit éditeur, les ESB arrivent avec toute une connectique permettant d adresser un large panel de technologies et de protocoles de communication. L ESB se présentant schématiquement comme un EAI sur lequel on aurait greffé une couche de standards (WS-*), son héritage des protocoles «legacy» entraine une mise à disposition d un ensemble de connecteurs permettant d adresser l hétérogénéité du patrimoine applicatif du SI. L effet pervers est de pérenniser des éléments «legacy», en conservant les interfaces «historiques» et donc, de reconduire leurs limitations. La tentation est toujours forte de penser ses besoins comme spécifiques plutôt que de tenter de résoudre leurs divergences par rapport à un standard. Cause Idéaliser l opportunité des capacités d intégration de l ESB en utilisant tout le panel des connecteurs disponibles. Bref : reproduire la logique de l EAI. Application verticale par branche métier Application composite multi-domaines pour processus transverses Application composite orientée processus IHM IHM Processus BPM Traitements Traitements Domaine fonctionnel de Services Domaine fonctionnel de Services Données Données Domaine de Services métier Domaine de Services métier Domaine de Services métier Flux EAI Diffusion d information Figure 4 : différence d approche EAI/ESB 22 IT-expert n 88 - novembre/décembre 2010

23 Technique Effet Dans un souci de rationalisation des interfaces applicatives, la tentation d utiliser l ESB comme un facilitateur d intégration au sens EAI est forte. Il faut garder à l esprit que la démarche sous-tendue par un ESB est bien de standardiser les interfaces et de fournir une couche d abstraction, médiation entre un consommateur et un fournisseur de service. L utilisation systématique de connecteurs applicatifs spécifiques ne sert pas cet objectif. L ESB propose alors une démarche d intégration type EAI, où il lui incombe de se plier aux interfaces spécifiques des patrimoines applicatifs. Le biais de ce principe est de faire porter par l ESB toute la connectique spécifique des applications «connectées», ce qui n est pas souhaitable dans une démarche globale de rationalisation. En effet, dans cette optique, il n est pas de sa responsabilité de porter cette rupture protocolaire. La démarche globale d adoption d une approche SOA s en trouve freinée, puisque l effort d adaptation n est plus porté par les services, mais par le médiateur. Solution Pour éviter ce type d anti-pattern qui a des impacts technologiques importants, il convient de poser des règles d architectures fortes, et de tenir le cap d une cible standard. Les recommandations sont donc plutôt d ordre organisationnel que purement architectural. Pour autant, il parait nécessaire afin de converger au plus tôt vers des interfaces normalisées de faire porter l effort de standardisation par les nouvelles applications plutôt que par le médiateur. Anti-Pattern #5 L Architecture slideware ou tour d ivoire Description Ce pattern, volontairement provocateur, se focalise sur la démarche de choix d outil ou d établissement d un cadre normatif avant d avoir clairement établi le besoin métier. Cette démarche est finalement assez fréquente puisque le biais est de plaquer des solutions existantes qui fonctionnent à un besoin spécifique. Cet anti pattern pourrait s appliquer à de nombreux contextes, mais il est particulièrement présent dans les projets ESB qui souffrent historiquement de la confusion avec les EAI. Cause Manque d analyse de ses propres besoins, d identification des exigences fonctionnelles et non fonctionnelles. Effet L effet peut s avérer désastreux tant en termes budgétaires, que de réponses aux besoins sous-tendus par l outil. Le résultat peut être d investir dans un outil dont l entreprise ne pourra utiliser toutes les fonctionnalités. Autre effet secondaire : l industrialisation d un certain nombre de patterns par méconnaissance du besoin et donc, surinvestissement dans une industrialisation de l outil. Le risque est également de mettre en place tout un framework, des patterns d utilisation qui n ont finalement que peu de lien avec les services cibles. Une conséquence complémentaire revient à mettre en place un certain nombre de connecteurs ou d éléments d architecture qui ne seront finalement pas utilisés. (cf. la tentation de l anti patterns «la multiprise»). Solution La recommandation peut paraitre simpliste : il s agit de fonctionner par démarche itérative, également pour la mise en place de l architecture. Trop souvent, on constate que la mise en place d un socle de services s effectue lors de la 1 re itération, sans prendre en compte les probables précisions/ évolutions des besoins. Il s agit également d identifier clairement le patrimoine applicatif que l on souhaite reconduire, ses limites d interopérabilités, ses capacités d évolution et sa trajectoire de migration vers l exposition via un ESB. L outil n est pas la solution Il existe de très nombreuses manières de faire échouer de bonne foi un projet autour d un ESB. Il n est pas rare de voir systématiquement l ESB présenté comme le successeur de l EAI et donc d en stéréotyper son usage. C est généralement le cas côté éditeur par le choix de capitaliser sur la dernière génération des EAI, en termes d offre logicielle. Cependant, Un architecte ne devrait pas se contenter de pérenniser les réflexes de l EAI. La mise en place d un ESB doit favoriser une démarche de standardisation des interfaces, enclencher une démarche SOA et favoriser l identification des responsables des données en limitant les flux au sein du SI. Pensons réponses aux besoins et non plus seulement outils! n Claude-Emmanuel Drexler, Manager, en charge de l offre ESB [email protected] Logica est l entreprise du service en business et technologie. Elle réunit collaborateurs. Elle propose conseil en management, intégration de technologies et externalisation à ses clients du monde entier, dont les plus grandes entreprises en Europe. Site web : IT-expert n 88 - novembre/décembre

24 Actualités internationales Google-Facebook : guerre ouverte entre les géants du Web Avec son projet de messagerie évoluée (projet Titan), Facebook vient chasser sur les terres de Google en concurrençant son service Gmail, mais aussi Yahoo! Mail ou Hotmail Fort de ses 500 millions de membres dans le monde, Facebook affronte sans complexe les ténors de l en ligne. Néanmoins, il faut relativiser ces 500 millions. Des millions (dizaines de millions?) de gens ont créé un compte Facebook qu ils ont depuis longtemps oublié. Autre problème : la plupart des internautes ont déjà adopté une plate-forme de messagerie en ligne qui est devenue leur adresse de référence. On se souvient que Facebook a déjà lancé la messagerie instantanée, face à GTalk et surtout à Microsoft Messenger ou Skype. Apparemment sans causer de dégâts significatifs. Estimant que Facebook ne respectait pas son devoir de réciprocité, Google a décidé de ne plus permettre l accès à son API faisant fonction de passerelle vers le réseau social, et qui permettait d importer ses contacts de Gmail. Le géant de la recherche sur Internet a déclaré qu il autoriserait ces échanges qu avec les sociétés qui permettent à leurs utilisateurs l exportation de contenu vers Google de manière aussi simple. Google annonce 170 millions d utilisateurs de son service Gmail dans le monde. Malgré la crise, Google aurait planifié des primes et des augmentations de salaire de 10 % pour enrayer la fuite des meilleurs éléments (selon le Wall Street Journal). La pénurie d ingénieurs expérimentés engendre la surenchère dans la Silicon Valley, et Facebook (encore elle) se serait largement servi chez Google! Une démarche globale, puisque des entreprises comme Google, Apple, Adobe ou Intel auraient signé un accord-cadre avec le ministère de la Justice américain pour éviter les chasses aux profils très qualifiés, qui migrent parfois en groupe vers des cieux plus accueillants. n TomorrowNow : Oracle réclame 4 milliards à SAP Le 8 novembre dernier, Larry Ellison - CEO d Oracle - a estimé à 4 milliards de dollars le préjudice subi dans l affaire qui l oppose à SAP sur TomorrowNow, rachetée par l éditeur allemand en 2005 et fermée en De quoi s agit-il? Cette société aurait eu accès à un logiciel Oracle et à un fichier de support client. Oracle avait jugé cette pratique malhonnête, et poursuivi SAP pour - entre autres - violation de propriété intellectuelle. Si SAP ne conteste pas les faits reprochés à TomorrowNow, la bataille porte maintenant sur l évaluation du préjudice. Pour SAP, un dédommagement de 40 millions de dollars semble suffisant. Selon la police ou selon les syndicats... La concurrence farouche et mondiale des deux entreprises sur les marchés du Progiciel, de la plate-forme applicative, de la Business Intelligence, de la base de données attise encore les passions, et transforme aussi ce jugement en bras de fer psychologique de premier ordre. n 24 IT-expert n 88 - novembre/décembre 2010

25 Actualités internationales Google offre le WiFi en vol Après une opération du même type dans 50 aéroports américains, Google offre le WiFi sur les vols intérieurs aux États-Unis. Du 20 novembre au 2 janvier, le géant du Web offrira la connexion WiFi aux passagers de 700 vols des compagnies AirTran, Delta et Virgin America, via le service Gogo Inflight. Cette opération est loin d être désintéressée, puisque Google en profitera pour faire la promotion de son navigateur Chrome sur la page d accueil à chaque connexion. Une belle opération de marketing croisé aussi pour Gogo Inflight. En effet, certains pourraient y prendre goût, surtout les habitués. Au WiFi en vol et peut-être à Google chrome. Allez savoir! n Dell veut aussi jouer dans le nuage Boomi? L éditeur de service en ligne de Pennsylvanie propose des services de déploiement et d intégration d applications en mode Cloud (SaaS ou Software as a Service). Son service AtomSphere simplifie l intégration de données entre applications, services Cloud et autres applicatifs hébergés. Et cette intégration «transparente» incarne justement un point crucial de l essor du Cloud : la capacité à s intégrer à l existant des entreprises (données comme applications), et la possibilité d utiliser le même jeu de données entre différents services Cloud. Avec cette acquisition, Dell se lance dans le segment de l intégration, segment déjà investi par Informatica, Tibco, mais aussi IBM, SAP, Oracle, Microsoft, ou plus récemment Talend. Un nouveau métier pour le constructeur, plutôt éloigné de son activité principale et exigeant des compétences et des approches totalement différentes. À suivre Le montant de la transaction n a pas été communiqué, pour cette société qui annonce des centaines de clients et des dizaines de milliers d intégrations. n Un million de pros français sur le nuage Microsoft Microsoft annonce avoir dépassé le million d utilisateurs pour ses services professionnels en mode Cloud en France, et 40 millions dans le monde. Début novembre, l éditeur lançait la version beta d Office 365, son offre Saas regroupant Office 2010 et ses outils collaboratifs Lync, SharePoint et Exchange. Confirmant son virage Cloud, avec sa propre vision conservatrice (Software+services, modèle de licences oblige.), Microsoft complète donc son catalogue. En effet, l éditeur de Windows s est déjà positionné sur le PaaS (Platform-as-a-Service) avec Windows Azure pour développer des applications Cloud, et sur l IaaS Infrastructure as a Service) avec Windows Server Hyper-V et System Center en mode Cloud. Toutefois, Microsoft préserve son écosystème en encourageant ses partenaires à développer des services Cloud sur ses plates-formes, un réseau précieux de 700 partenaires ( dans le monde) qui revend aussi les Microsoft Online Services. De là à distinguer services hébergés et services Cloud le marketing prend le dessus! n IT-expert n 88 - novembre/décembre

26 Peur d Hadopi : pirates ou menteurs? Un sondage BVA-La Tribune de novembre 2010 montre que plus de la moitié (53 %) des internautes qui téléchargeaient de façon illégale régulièrement auraient cessé cette pratique depuis le vote de la loi Création et Internet en octobre Le gendarme et le bâton auraient-ils eu raison de la piraterie des rebelles français? Le second volet de la loi Hadopi (Haute Autorité pour la diffusion des œuvres et la protection des droits sur internet) adopté en septembre dernier, avec envoi d s d avertissement, aurait-il conforté cette tendance apparente? Rien n est moins sûr. En effet, sur l échantillon de personnes interrogées pour l étude, seuls 17 % reconnaissent avoir piraté des fichiers (musiques, logiciels, films ). Et même si ce chiffre passe à 48 % chez les ans, ces deux résultats semblent très optimistes. En toute bonne foi, certains internautes effectuent une recherche sur un moteur et arrivent sur un site proposant le téléchargement, tout en proposant d acheter aussi le fichier ou l application. Difficile alors de savoir que ce téléchargement est illégal. En outre, les multiples visionnages de films en streaming sont souvent considérés comme légaux par l internaute qui ne télécharge rien sur son ordinateur Par ailleurs, la vente de disques externes et internes se porte très bien. Mais que peuvent donc enregistrer tous ces internautes? Et quel site de téléchargement légal est-il soudain devenu milliardaire? n Microsoft propose son antivirus via Windows Update Après détection de l absence d antivirus sur le poste de travail, Microsoft propose son antivirus gratuit Security Essentials via une mise à jour optionnelle de Windows Update (la mise à jour automatique de Windows). Après un positionnement grand public, Microsoft élargit maintenant la cible de son antivirus gratuit aux entreprises de moins de 10 postes. Il faut croire que l éditeur des Windows n est pas satisfait des 30 millions utilisateurs de Security Essentials. Après une première initiative au Royaume-Uni, cette procédure arrive aux États-Unis. Pour ne pas se mettre les éditeurs d antivirus à dos, Microsoft reste sur une mise à jour optionnelle limitée aux postes sans antivirus. Ces derniers mettent toujours en avant leur R&D et leur avance technologique face aux solutions gratuites. À voir n Oracle met un milliard sur ATG Les géants de l informatique disposant encore de beaucoup de trésorerie, la croissance externe se poursuit à coups de milliards. Parmi les dernières acquisitions, Oracle a mis la main sur l éditeur américain ATG (Art Technology Group) pour un milliard de dollars cash! ATG publie une plate-forme d e-commerce et de transactions on-demand. Parmi les fonctions évoluées favorisant le suivi du client : merchandising, marketing, personnalisation de contenu, recommandations automatiques (cross-selling) et assistance en ligne. Autant de fonctions qui viennent enrichir les applications CRM, ERP, SCM (gestion de la chaîne des approvisionnements) d Oracle. Une fois le rachat validé par les autorités de régulation américaines début 2011, les solutions d ATG devraient «fusionner» dans l offre Oracle. n 26 IT-expert n 88 - novembre/décembre 2010

27 Actualités internationales Les Français plébiscitent le travail à distance Plus de la moitié des Français pensent que leur présence systématique au bureau n est pas indispensable. Toutefois, ces aspirants au travail à domicile exigeraient d accéder simplement et via tout équipement à leur environnement de travail numérique. Menée auprès de professionnels du secteur des technologies de l information dans 13 pays, l étude InsightExpress (pour Cisco) montre quelques écarts entre la France et la moyenne européenne. Ainsi, 60 % de l échantillon estime «la présence physique au bureau n est plus indispensable pour garantir la productivité», contre 56 % des Français et 66 % des Anglais. En Asie et en Amérique latine, on passe à 93 %, et à 81 % en Chine! Et la majorité des sondés préfèrent un poste moins payé avec accès mobile que mieux payé et moins flexible. Bien entendu, l étude est commandée par Cisco, vendeur de solutions réseau, de logiciels de communication et de serveurs blade Néanmoins, cette tendance s accentue, et mieux vaut la prendre en considération. Nombre de salariés se plaignent de ne pouvoir se connecter au réseau de leur entreprise. Le record va aux Russes avec 83 %, suivis des Allemands à 77 %, de l Inde à 74 %, et de la France à 72 %! Pour les autres, 45 % assurent se connecter 2 à 3 heures par jour pour continuer à travailler (48 % en France). Objections avancées à ce manque d ouverture : la sécurité (57 % des sondés) et le budget (34 %). En outre, 58 % des sondés reconnaissent avoir permis à des personnes extérieures d utiliser le matériel fourni par leur entreprise et 26 % des professionnels informatiques ont déclaré du matériel perdu ou volé au cours des 12 derniers mois. On le sait depuis longtemps, la sécurité est un mal qui vient souvent de l intérieur. Mais quand on veut tuer son chien, on l accuse de la rage. Enfin, offrir une possibilité ne signifie pas forcément tout bouleverser dans les modes de travail. n Reprise de l emploi pour les informaticiens ! C est le nombre de recrutements réalisés dans l industrie informatique en France en 2010 (dont cadres), contre en Pas loin du record de atteint en Et selon le Syntec Numérique le mouvement devrait perdurer en ce sens en Les plus dynamiques? Les éditeurs, les SSII et les prestataires avec un total de embauches, dont 80 % assurent maintenir ce rythme au quatrième trimestre. Sur un marché générant une valeur de 41 milliards d euros en 2010, le Syntec prévoit une hausse de 3 % des revenus en 2010, due à l augmentation des budgets informatiques pour 53 % des entreprises de l Hexagone. Néanmoins, les postes de chefs de projets et d architectes informatiques opérationnels se font rares, et les jeunes diplômés ne sont pas toujours opérationnels. C est pourquoi nombre d entreprises informatiques créent leurs propres formations internes afin de «mettre à niveau» les nouveaux embauchés. Le défi consiste ensuite à les fidéliser. Pour sensibiliser les jeunes à des métiers prometteurs, le Syntec Numerique a ouvert les sites à destinations des étudiants, mais aussi des parents et des professeurs. n IT-expert n 88 - novembre/décembre

28 Les visions dynamiques de l Architecte d Entreprise 28 IT-expert n 88 - novembre/décembre 2010

29 Comment ça marche? Le paradoxe des visions globales Depuis plusieurs décennies, on constate les aléas, parfois les errements, des projets de systèmes d information : budgets et délais dépassés, objectifs illusoires, utilisateurs frustrés, complexité superfétatoire Peut-on encore croire à des projets sensés définir des «besoins», les inscrire dans des «spécifications» reliées dans un idéal «cahier des charges»? Cela ne correspond pas aux nombreux retours d expérience, et ce constat est durable. Certes, on peut espérer raccourcir le détour qu impose un investissement SI, par exemple grâce à un développement agile, ou au recours à un progiciel, ou encore en mettant en œuvre une architecture flexible, composée de services. Pourtant, au-delà de toutes les précautions méthodologiques, de recettes miracles dans l ingénierie de construction du SI, des nombreux détours de modélisation, il existe un paradoxe propre au monde du SI et des processus : disposer d une vision globale, claire et compréhensible, et qui transcende les SI comme les processus, est rarissime. La règle quasi générale est, pour des raisons diverses et variées, l inexistence de ce niveau de vision, qui permettrait pourtant de valider les grandes options du projet. Sans une telle vision, comment sécuriser un projet, au moins sur ses fondamentaux? Comment garantir l alignement stratégique? Dans le monde réel, celui des projets tangibles, on élabore des cartes d état-major, des images de projets aux résultats visibles dans leurs grandes lignes, dans leur insertion. On anticipe à peu de frais des représentations fidèles sur des maquettes. Mais quand il s agit de SI et processus, qui soutendent la machinerie des entreprises et organisations de notre époque, on se perd : Soit dans des «big pictures» qui, en voulant tout représenter donnent naissance à des schémas abscons, repoussoirs pour le commun des mortels, images ésotériques et brouillonnes dans leur tentative de tout dire et de plaire à toutes les parties prenantes, des stratèges, aux métiers, au monde du SI. Soit dans un détail impertinent de modèles de processus ou de SI, où la finalité est perdue et où seuls les spécialistes s y retrouvent, et s y confortent, Soit dans le mirage de stéréotypes à tout faire, sensés représenter toute entreprise, alors que cellesci sont si différentes et confrontées à des marchés si variés. Voilà l un des paradoxes de notre monde hyper complexe, où l on a plus de plaisir à imaginer des tunneliers, à creuser des tunnels, qu à objectiver clairement où l on va. Pourtant la réalité n est pas si complexe qu on voudrait le faire croire, et on gagne à s abstraire d une foule de contingences et de détails, qui ne sont que péripéties dans le mouvement des affaires, des organisations, et des projets qui en découlent. Objectiver les transformations Une vision transcendant SI et processus Pour se doter d une vision globale, il faut être en mesure de représenter, non pas tous les détails «mécaniques» des SI et des processus, mais leurs flux entrants et sortants : en somme représenter les «transformations» que toute entreprise réalise pour produire, créer ses nouveaux produits et services, distribuer, gérer ses ressources, modifier son patrimoine SI, etc. Car cette notion simple, que l on comprend facilement dans le cas d une transformation matérielle, s applique pareillement à l immatériel. L effort de représentation ne porte plus alors sur le détail de la transformation : les péripéties du processus, qui résultent de choix opératoires, les spécifications du SI, qui découlent de l ingénierie entre le formel, et l informel, le contraint et le subsidiaire, le besoin supposé et le besoin réel. IT-expert n 88 - novembre/décembre

30 L effort porte sur l objectivation des transformations : quelles sont les données d entrée, les contraintes à respecter qui sont immuables, les ressources mobilisées et consommées, les étapes avec leurs résultats intermédiaires, produits semi-finis de la transformation, et les sorties sous forme de résultats : produits matériels fabriqués, services rendus, futures prestations définies? Car la réalisation elle-même de la transformation est naturellement variable selon les configurations économiques, les organisations mobilisées, la logique des processus mis en œuvre, les automatismes implantés par le SI une telle abstraction est salutaire pour se donner la vision recherchée. Le recours à l abstraction est pratique courante, par exemple les professionnels du SI sont familiers avec les déclics d abstraction, qui permettent d abstraire une «application» par une fonction, ou de définir un objet «générique», etc. Des transformations imbriquées Néanmoins, on constate qu une telle abstraction globale ne s est pas imposée. Car, si on sait décrire dans son essence même, en la sublimant des SI, processus et organisations, une seule transformation, on ne tient pas pour autant la vision globale et claire recherchée. En effet on ne résumera jamais une entreprise ou organisation, dans sa complexité «systémique», à une seule transformation : plusieurs transformations s y combinent subtilement, et collaborent en dynamique pour sauvegarder ses biorythmes, et vivre son développement. Il s agit de comprendre cette dynamique et se doter d une vision desimbriquée des transformations, pour ne pas voir l entreprise comme un fatras en mouvement brownien, et se détacher des variantes d organisations, résultantes de choix contingents. Désimbriquer, car toute entreprise et organisation est multiple : certes on peut objectiver le cycle productif, mais celui-ci n a pas de sens si les produits ou services sont immuables, le cycle de vie des produits est tout autant nécessaire. Il faut également distribuer ces produits selon un cycle propre lié à la logistique, à l animation des marchés, agité par les saisons, les campagnes, au travers d un réseau lui-même en constante transformation Une représentation des «chaînes de valeur» Ce qui vient d être dit correspond finalement à une représentation des «chaînes de valeur» et de leur synergie. À condition de bien s entendre sur le terme «valeur», et d être prudent, car il est galvaudé. En effet, le mot est mis à toutes les sauces, ayant la vertu d une rassurante ambigüité sémantique. Il permet au discours de ratisser large, pouvant être entendu sur un spectre sémantique qui couvre le moral, a priori transcendant toute métrique, jusqu à l opposé, résultat d une mesure, expression d une certitude «scientifique»! Le parti-pris est donc de ne se référer à aucune notion de «valeur», c est-à-dire d évaluation, quelle soit morale, économique, stratégique, probabiliste D ailleurs les fluctuations économiques on ébranlé bien des illusions de valeur. On doit en toute rigueur focaliser l analyse sur la chaîne de transformation, sur ses étapes, sa mécanique implacable, pour en dégager les fondamentaux, les invariants, en s abstrayant des valeurs, organisations, SI et processus. Dés lors, pour représenter le jeu de construction des chaînes de valeur, dans cette acception, on a tout avantage à se doter d une symbolique simple, afin de produire des schémas typiques et comparables d un business à l autre. C est l objectif de l outil de cartographie des chaînes de valeur EDA-kit (Event Driven Architecture kit). 30 IT-expert n 88 - novembre/décembre 2010

31 Comment ça marche? Cartographie d un univers de transformations Une telle représentation des chaînes de valeur suppose un formalisme. Les normes de modélisation disponibles sont dédiées aux différents modèles de SI ou de processus, et donc inadaptées à une vision globale. En général, pour représenter des «macroprocessus» ou des «domaines» du SI, par exemple dans un POS (plan d occupation des sols) d urbanisme du SI, on se contente de disposer des rectangles couvrant, sans convention particulière, un espace symbolisant tout ou partie de l entreprise. Ces formalismes sont soit trop détaillés, soit trop statiques pour tracer les transformations. Le parti-pris ici est de cartographier un «univers» de transformation. Ce terme désigne la carte des différentes opérations réalisées, quels qu en soient les opérateurs, pour une ou des transformations fondées sur un seul et même cycle. L idée consiste à se fixer sur l événement initiateur de la transformation, et de constater que cet événement n est jamais isolé, mais toujours instant d un cycle : chaque événement d un cycle est initiateur de transformations induites. On trouve aisément de multiples exemples de ce précepte : événements de «parcours», parcours d un passager, parcours client, parcours de soin, événements de «cycle de vie», cycle de vie d un composant matériel, cycle réglementaire, cycle de vie d un produit Dans tous ces cas, de multiples transformations sont initiées, pour assurer la maintenance du composant, fournir les prestations au patient, transporter le passager, faire évoluer le produit La carte de l univers de transformation fait ainsi apparaître, sur une ligne horizontale développant sa dynamique de gauche à droite, le cycle ou le parcours. C est une dynamique objective, invariante. Sous cette ligne, la carte positionne les différentes opérations qui correspondent à des grandes étapes de la transformation. Périmètre de la plateforme Programmation des vols Attribution des slots Attribution des ressources Contrôles Déchargement Rotation Chargement Autres prestations Autour de l'avion Décollage Atterrissage Vol Gestion et régulation du trafic aérien Contrôles Sûreté Sécurité Assistance Traitement Avion Contrôle aérien de la plateforme Opérateurs de la plateforme Intégrateur de services aux opérateurs de la chaîne de transport Intégrateur Propriétaire et intégrateur des installations de la plateforme Compagnie aérienne Entretien-maintenance-logistique Fournisseurs et opérateurs des systèmes industriels Opérateurs industriels Parcours Avion Le formalisme utilisé ici est celui proposé par l outil de cartographie des chaînes de valeur EDA-kit. Dans l exemple de l univers «parcours avion» d un aéroport, on trouve ainsi : La série des événements typiques du vol et séjour de l avion à l aéroport Les transformations réalisées, en rapport à ces événements, par les opérateurs de la plateforme, qui apportent un service adapté à l événement, un service de proximité La mise en cohérence de ces apports, et l intégration du flux avion et du flux passager, qui constitue le «cœur de métier» de l aéroport, qui se comporte ainsi en intégrateur de services Dans un même ordre d idée, l intégration des services d équipement et d entretien de la plateforme Enfin une série d opérateurs spécialisés par type de ressource, et qui interviennent au sein de l écosystème aéroportuaire : prestataires d entretien technique, fournisseurs de service. L aéroport, pour le seul cycle du parcours avion, apporte sa valeur au travers de multiples opérateurs en interaction constante, et sous l orchestration de l autorité aéroportuaire. IT-expert n 88 - novembre/décembre

32 Généralisation du concept d univers de transformation L exemple de l aéroport est aisément compréhensible, car la transformation de l avion y est en quelque sorte tangible. On comprend aussi facilement que représenter le seul parcours avion est réducteur, et qu il y existe aussi un «parcours passager», avec un univers de transformation typique, que l on retrouve «instancié» certes de façon différente, pour tout aéroport. Périmètre de la plateforme Préparation du voyage Acheminement Stationnement Information, déplacement, services aéroportuaires Commerces, hôtels, restaurants Contrôle Enregistrement Embarquement Débarquement, livraison bagages Vol Superviseur Services Contrôles sureté, Agence de voyage du réseau de Opérateur parking aux passagers Commerces sécurité (PIF, Assistance l'aéroport (salons ) police ) Opérateurs de la plateforme Intégrateur de services aux opérateurs de la chaîne de transport Intégrateur Propriétaire et intégrateur des installations de la plateforme Compagnie aérienne Entretien-maintenance-logistique Fournisseurs et opérateurs des systèmes industriels Opérateurs industriels Parcours Passager Dans cet univers «passager», les opérateurs de proximité sont dédiés au traitement des événements du passager, tout en étant là encore orchestrés par l autorité aéroportuaire, qui gère en outre la synchronisation des flux passager et avion. On voit, sur ce simple exemple, tout le parti que l on peut tirer d une représentation séparée des transformations «passager» et «avion», tout en préservant la cohérence d ensemble de l entité aéroportuaire et de son écosystème. De façon plus générale, comme on le laissait entendre précédemment, les mêmes lois «mécaniques» de transformations s appliquent à tous les cas de figure, que les cycles ou parcours concernent des objets matériels ou virtuels, des personnes physiques ou morales, des produits, des services, des réglementations, des éléments de patrimoine, des outils industriels, des réseaux sociaux, etc. Dès lors le formalisme sera identique, et d autres types d univers pourront être représentés avec le même outil cartographique, pour symboliser les diverses transformations propres à l entreprise. Et cette vision globale desimbriquée ne s arrêtera pas aux frontières de l entreprise, qui sont en constante évolution, mais à celles de l écosystème où celle-ci opère. On trouve par exemple le schéma de synthèse (page suivante) correspondant à l univers du soutien des services, tel qu il découle des préconisations d Itil. Ce type de schéma est précieux pour la stratégie de mise œuvre et d organisation dans le contexte Itil, car il permet d objectiver les diverses répartitions organisationnelles entre les composantes de service dégagées par Itil. De fait Itil propose un modèle de chaîne de valeur des processus de production informatique, modèle qui doit être instancié pour le cas de l entreprise, d abord de façon globale avec des cartes de ce type, puis de façon détaillée. 32 IT-expert n 88 - novembre/décembre 2010

33 Comment ça marche? Initial Incident Resolution Closure Change Information Support Service Desk Service Operator Incident Management Problem Management Change Management Configuration Management Integrator Data resource (CMDB) Resource Service Support Universe Un autre exemple correspond à un univers crucial pour toute entreprise : la création de l offre. Ainsi le schéma ci-dessous matérialise les transformations réalisées par une enseigne de distribution pour créer son offre : Suivre l offre de produits, et les émergences ou obsolescences (cycle de vie des produits). Analyser la demande des marchés pour la cible de clientèle et les segments visés (cycle exogène des marchés). Faire les choix marketing intégrant ces 2 visions et référencer les produits. Construire une offre intégrée et déclinable par enseigne, réseau, canal, campagne. Adapter les offres des produits et de leurs supports marketing aux cycles des campagnes (cycle de mise en campagne). Il est clair que ces transformations sont propres à la stratégie de l entreprise, qui pourra faire des choix de configuration économique particuliers pour intégrer en son sein ou au contraire sous-traiter telle ou telle fonction. Dans d autres secteurs économiques, la création de l offre serait très différente, impliquant par exemple une importante transformation de recherche-développement Industrial Product Life Cycle Market Cycle New product announcement Product specifications Product Availability Product Evolution End of Life Cycle Market Variation Development Maturity End of Cycle Purchase Operator Market Analyse Service Operator Product Marketing Product Integration Service Operator Advertising Sales development Integrator Campaign Definition Campaign begining Campaign Development Maturity End of Campaign Market Cycle Offer Creation IT-expert n 88 - novembre/décembre

34 Un outil de l Architecte d Entreprise L outil de cartographie EDA-kit, porteur de la méthode de modélisation des chaînes de valeur «Trame Business», la met en pratique en quelques clics. Basé sur Microsoft Visio, il permet de représenter des scénarios, en jouant en particulier sur la technique des calques de Visio. Il a ainsi du sens pour l Architecte d Entreprise dans l acception la plus globale du terme. Avec une prise en main simplifiée, il est à l Architecte d Entreprise ce qu est un outil de maquettage, de DAO, pour l architecte. L outil permet des publications Web, par exemple dans un intranet, et autorise un lien dynamique avec les autres publications plus détaillées (SI et processus), proposées par les outils du marché. Par la simplicité du formalisme, son caractère adaptable pour coller au business et au métier, c est un moyen de communication entre les décideurs, les Architectes d Entreprise, les responsables des SI et des processus. Le dessin et le long discours Le modeste outil ainsi décrit concrétise la logique que nous venons de développer : se concentrer sur l essentiel, qui est le terrain des évolutions des entreprises et organisations, et sur lequel s implémentent les valeurs du moment, et les choix de manœuvre. Il ne présente que peu d objets, et n a pas vocation au détail de processus, de SI, de variantes d organisation, et d investissements en tout genre. Se trouve ainsi comblé le manque de vision de haut niveau, là où les enjeux sont les plus forts. Un grand acteur de la distribution d énergie a adopté ainsi une «cartographie des macroprocessus» tenant sur une seule page et représentation de référence de son métier. Certes de tels schémas ne proposent de solutions complètes, armées de leurs quantifications. Dans le cas d aéroport par exemple, il existe de nombreuses différences de configuration de l écosystème, l aéroport pouvant appartenir à une compagnie aérienne, ou pouvant assurer de nombreuses prestations de la plateforme, voire avoir ses propres boutiques. Il peut au contraire se concentrer sur la seule fonction d intégration de l ensemble. Quantifier et détailler toutes ces alternatives seraient un travail lourd, et en partie inutile. Mais, en réalité, le modèle reste le même, et permet alors de présenter toutes ces variations de frontière d entreprise, et de dégager les pistes à approfondir. Et, dès ce niveau sommaire, des questions se posent qui orientent la recherche des chemins de manœuvre stratégiques. Quelques jeux de couleurs, quelques bulles d interrogation, y pourvoient. En somme, ce type de schéma «d Architecture d Entreprise»est ancré systématiquement sur les invariants du métier, il relativise les visions de l existant, des cibles, et des migrations. Le dessin porte en germe le discours sur les fondamentaux, nécessaire à l alignement stratégique. n René Mandel, Fondateur René Mandel, a développé ses compétences d abord dans l informatique de l Administration, puis dans le consulting, fondateur d ORESYS, et un des promoteurs de l urbanisme des SI, avec la création du Club Urba-EA. Créateur de la méthode PREMYS d urbanisme et de l architecture des systèmes d information, et de la méthode de modélisation d Architecture d Entreprise TRAME BUSINESS. Auteur de l ouvrage : «De la Stratégie Business aux Systèmes d Information, l entreprise et son écosystème» Hermès Acteur majeur du conseil en management et organisation, Oresys est une société indépendante de 230 consultants basée à Paris, Lyon, Bruxelles qui aide ses clients à piloter leurs activités, améliorer la performance et mettre en œuvre leurs projets de transformation. ORESYS intervient sur toutes les dimensions : métiers, organisation, processus, système d information, accompagnement du changement. ORESYS est membre fondateur du club URBA-EA ( ). Site web : 34 IT-expert n 88 - novembre/décembre 2010

35

36 La gouvernance du patrimoine applicatif optimisation de la qualité applicative Souvent complexe et hétérogène, le patrimoine applicatif de l entreprise est pourtant essentiel à l activité métier. Il peut être composé de progiciels d origines multiples (multivendeurs, développements internes, etc.), aux langages de programmation divers, avec une gestion et des compétences pas toujours maîtrisées par l entreprise. Difficile d évaluer la qualité de ces applications, d estimer leurs coûts et de prendre les bonnes décisions pour faire évoluer ce patrimoine applicatif. Toutefois, des solutions permettant l analyse des applications existent pour aider à leur gouvernance. 36 IT-expert n 88 - novembre/décembre 2010

37 Quoi de neuf Docteur? Qu entend-on par gouvernance applicative? La Gouvernance applicative recouvre les fonctions et solutions permettant d analyser, d évaluer et de faire évoluer le patrimoine applicatif de l entreprise en fonction des besoins utilisateurs. Elles facilitent également l optimisation des coûts sur ces applications via des ratios coûts/bénéfices. Derrière le terme un peu généraliste de Gouvernance se cache une pluralité de solutions aux périmètres fonctionnels distincts. La gestion des applications se retrouve tout au long des différents livres ITIL (Information Technology Infrastructure Library ou Bibliothèque pour l infrastructure des technologies de l information). Elle se retrouve notamment dans le livre Service Operation (exploitation des services). Dans ce livre, la Gestion des Applications apparaît comme la fonction visant à gérer les applications tout au long de leur cycle de vie, que ces applications soient achetées ou développées en interne. Elle vise à identifier les exigences et besoins fonctionnels pour le développement applicatif, à aider le design et le déploiement des applications, à gérer le support et l amélioration continue des applications. On peut identifier trois groupes de solutions pour la gestion du patrimoine applicatif d une entreprise. Chaque groupe englobant plusieurs segments de marché : les solutions de type décisionnelles ou stratégiques offrent une vision de «haut niveau» sur les applications GOUVERNANCE APPLICATIVE et permettent d obtenir une vision d ensemble sur le parc applicatif de l entreprise, les solutions d analyse applicative offrent une analyse détaillée des applications sur un périmètre précis : qualité du code, performance applicative, niveaux de service, etc. les solutions de gestion applicative opérationnelles proposent des fonctions pour concevoir, déployer, supporter, DÉCISIONNEL ANALYSE OPTIMISATION faire évoluer ou optimiser directement les applications. Figure 1 - La gouvernance applicative (Source le CXP, 2010) Figure 2 Quelques segments de marché de la Gouvernance applicative Figure 2 Quelques segments de marché de la Gouvernance applicative (Source le CXP, Source 2010) le CXP, 2010 IT-expert n 88 - novembre/décembre

38 Optimiser la qualité applicative Les solutions d analyse du code applicatif aident à «parser» le code applicatif d une application. Cet anglicisme signifie analyser syntaxiquement un texte (en linguistique) ou un code (en informatique). Un parseur est un logiciel permettant d analyser la structure d un code applicatif. Il est souvent spécifique à un langage (Java, Cobol...), mais les éditeurs ont développé des parseurs génériques permettant d analyser globalement tout type de langage. Il existe plusieurs normes concernant la qualité applicative. Parmi les plus connues, la norme ISO/IEC 9126 (2001, 2002, 2003, 2004) intégrée dans la norme ISO SQuaRE (Software product Quality Requirement and Evaluation, 2005). Cette norme définit des caractéristiques logicielles facilitant l évaluation de la qualité applicative. Le modèle qualimétrique est le suivant : capacité fonctionnelle, fiabilité, facilité d utilisation, efficacité, maintenabilité et portabilité. À partir de cette analyse syntaxique du code, les solutions sont capables d alimenter des mesures et des indicateurs sur la qualité applicative (ex. : maintenabilité, évolutivité, etc.), l ensemble des indicateurs formant le modèle qualimétrique. Globalement les indicateurs de ces modèles suivent de multiples normes et standards (voir encadré). Ces solutions permettent également d évaluer la qualité du développement applicatif selon des règles de développement et des bonnes pratiques de programmation définies par les langages (ex. : conformité avec les règles de nommage, documentation, pourcentage de commentaire, code mort, etc.). Principaux gains et bénéfices Les solutions d analyse de la qualité applicative se destinent à plusieurs typologies de profils avec différents besoins : les responsables informatiques pour suivre l état du patrimoine applicatif, les coûts et les risques ; les responsables d application ou de projets pour contrôler l état des applications selon leurs périmètres respectifs et prendre les actions correctives au niveau de leurs équipes ; les contrôleurs qualité pour évaluer les niveaux de qualité et les optimiser ; les architectes pour identifier la cartographie applicative, les relations et gérer l architecture ; les développeurs pour identifier les impacts de demandes de changements, identifier les parties de code à améliorer et identifier les bonnes pratiques et règles à suivre ; les prestataires externes pour identifier les normes et règles de développement à respecter. Ces différents utilisateurs nécessitent également des vues spécifiques en fonction de leurs attentes : indicateurs de «haut niveau» pour les responsables informatiques, suivi des normes de qualité pour un contrôleur qualité, vues détaillées du code applicatif pour les développeurs (drill down). L analyse de la qualité applicative permet de répondre à plusieurs enjeux : la gouvernance et le pilotage du patrimoine applicatif, le suivi opérationnel des applications, le contrôle de la qualité et l optimisation des développements. Autant de réalisations favorisant la maîtrise de son parc applicatif et de son évolution. 38 IT-expert n 88 - novembre/décembre 2010

39 Quoi de neuf Docteur? Une palette de fonctions intégrées Les solutions d analyse et d optimisation de la qualité applicative proposent différents types de fonctions, plus ou moins bien gérées et complètes selon les éditeurs. Cartographie & inventaire Analyses du code Tableaux de bord Gestion des coûts applicatifs Exports, rapports et documentation Identification et traitement des erreurs Optimisation Ces logiciels proposent des fonctions de cartographie réalisées à partir de l analyse statique du code source. La gestion de la cartographie et l inventaire peuvent être effectués de façon graphique (identification des composants et représentation des liens sous différentes formes de graphiques, en étoile par exemple) ou textuelle. Cette cartographie facilite l analyse des dépendances et notamment l analyse d impact en cas de modification sur un des composants. Ici, il s agit d analyser le code source d une application. Ces solutions visent non seulement l analyse de la qualité du code, mais également l analyse de l architecture applicative (comme la relation entre composants). L analyse vient alors alimenter les mesures afin d enrichir les indicateurs et les modèles qualimétriques. Certains éditeurs proposent des modèles qualimétriques en standard, souvent basés sur la norme ISO Les modèles qualimétriques, les mesures les constituant et les seuils sont plus ou moins facilement modifiables selon les solutions. En outre, toutes les solutions ne proposent pas la même couverture en termes de langages, technologies et applications. Certaines sont monotechnologie et ne permettent -par exemple- que d analyser les applications de code Java. Les modèles qualimétriques peuvent être suivis dans des tableaux de bord, plus ou moins graphiques et interactifs. L objectif de ces tableaux de bord est de proposer différentes vues en fonction des profils utilisateurs. Ainsi, un responsable informatique ne sera pas préoccupé ni intéressé par les mêmes informations qu un développeur. Les éditeurs ont également développé des fonctions de drill down, plus ou moins complètes, qui permettent d accéder, à partir d un indicateur, directement au code source. Enfin les tableaux de bord peuvent remonter des informations techniques sur la qualité applicative, mais peuvent aussi croiser ces informations avec des données liées aux activités de l entreprise (ex. : niveaux de service, éléments administratifs sur les applications, ressources et compétences, etc.). Certaines solutions permettent de gérer les coûts relatifs aux applications. Ces coûts peuvent être estimés selon la méthode des points de fonction, ou par analyse des rapports modification/temps passé/coûts des ressources. Ainsi, il est possible d estimer les modifications réalisées entre deux livraisons afin d en déduire un temps de travail et le coût associé (qui sera évalué selon le coût horaire des ressources). Ces fonctions sont notamment utiles pour évaluer et suivre les prestations externalisées, mais aussi les refacturations internes. Les solutions proposent également des fonctions d exports, utiles notamment pour l export des règles de codage (par exemple à destination des prestataires de service) et des fonctions de reporting sous différents formats. Elles offrent aussi des fonctions de rétrodocumentation applicative permettant d améliorer la connaissance technique d une application. À partir des indicateurs et mesures, ces logiciels permettent d explorer le code source des composants qui s y rapportent pour identifier le code en défaut pour une règle de qualité. Certaines solutions offrent même des fonctions permettant directement de modifier le code source afin d assurer le respect scrupuleux des règles et pratiques. Le développeur dispose également de plug-ins dans les environnements de développement permettant de suivre directement, de contrôler et de modifier son code pendant ou après son développement. Ces solutions permettent aussi de définir des objectifs de qualité à respecter suivant des seuils prédéfinis. L utilisateur peut alors suivre dans le temps l évolution des mesures et des tendances sur ces objectifs. Certains logiciels offrent une gestion de plans d action pour aider à résoudre ou améliorer la qualité. On trouve même parfois des fonctions de benchmarks (tests comparatifs) pour comparer la qualité d une application à d autres applications de même type, ou à de précédentes versions. IT-expert n 88 - novembre/décembre

40 Un marché très disputé Gestion de la qualité applicative Généralistes ASG Cast McCabe Metrixware Micro Focus Mono technologies et Open Souce Gestion de lportefeuilles applicatifs Acteurs domaine applicatif IBM Cast Metrixware Micro Focus Speedware Acteurs PPM Checkstyle (OS) IBM Metaware PMD (OS) Polyspace Compuware Planview Serena Figure 3 - Positionnement des produits (Source le CXP, 2010) Le contrôle et l optimisation de la qualité applicative sont souvent du ressort d acteurs spécialisés avec deux orientations : des acteurs qui proposent une offre fonctionnellement large sur de multiples langages et technologies et des éditeurs positionnés sur une seule technologie (qui peuvent être des acteurs de l open source). La gestion de portefeuilles applicatifs peut être gérée par ces mêmes acteurs issus du domaine applicatif. On retrouve également des acteurs issus de la gestion de portefeuilles de projets (PPM ou Project Portfolio Management). Ces derniers proposent des fonctions APM ou Applicaton Portfolio Management dérivées de leurs fonctions dédiées à la gestion des demandes et projets informatiques. n Laetitia Bardoul, Senior Analyste Le CXP, Centre d expertise des Progiciels, principal cabinet indépendant d analyse de logiciels en France, identifie de manière exhaustive les fournisseurs de progiciels et évalue en détail leurs fonctionnalités, les caractéristiques de leurs éditeurs et des réseaux de distribution et les intégrateurs. Sa méthodologie unique garantit une véritable indépendance et fournit une vision objective pour sélectionner les meilleurs progiciels pour des systèmes d information au service de l entreprise et de ses évolutions. Documents CXP associés Service expert «La gouvernance du patrimoine applicatif - focus optimisation de la qualité applicative» Le contenu de cet article est extrait de l étude «Gouvernance du Patrimoine applicatif, focus optimisation de la qualité applicative» qui peut être téléchargée : Etude d opportunité Documents à l unité d analyse des offres : ASG, Cast, Metrixware, Micro Focus. 40 IT-expert n 88 - novembre/décembre 2010

41 Livres Expression des besoins pour le système d information Nombre de projets dépassent les délais, mécontentent les utilisateurs et coûtent finalement très cher pour ne répondre finalement que partiellement aux attentes de l entreprise. Souvent, un besoin exprimé par l utilisateur demande à être «fouillé» pour aboutir au besoin réel. Riche de sa longue expérience de terrain, Yves Constantinidis déroule une démarche basée sur un exemple réaliste, et enchaine les étapes jusqu à la rédaction d un cahier des charges satisfaisant pour tous, et surtout pour l utilisateur final! Incompréhensions, demandes divergentes, des contraintes multiples L auteur détaille les étapes de ce parcours semé d embuches avec des solutions éprouvées : définition des objectifs et du périmètre, planification de l élaboration ; les quatre grandes étapes recueil, analyse, spécification et validation Riche en modèles de documents, en grilles et en check-lists, cet ouvrage deviendra le compagnon de route du chef de projet, de l assistant à maîtrise d ouvrage, du consultant, des experts techniques et métier De tous ceux qui savent combien l expression du besoin conditionne la réussite de tout projet informatique. Expression des besoins pour le système d information Guide d élaboration du cahier des charges Yves Constantinidis Éditeur : Eyrolles 246 pages - environ 35 Moderniser son système d information La souplesse et la réactivité de l entreprise sont souvent pénalisées par un système d information vieillissant, voire inadapté. Une situation qui devient rapidement un handicap face à la concurrence, surtout dans une PME/PMI. L auteur propose une approche pour évaluer le potentiel de création de valeur du SI et de sa capacité d adaptation : cartographie applicative, analyse de valeur, référentiels, risques, etc. Outre les besoins en réorganisation, l ouvrage explique comment la modernisation du SI et son pilotage avisé à l échelle de l entreprise peuvent favoriser la transformation indispensable pour que le SI devienne enfin un levier et non plus un poids dans le déploiement opérationnel de la stratégie, aussi modeste soit-elle. L entreprise peut ainsi se libérer du poids du passé informatique et bénéficier d un SI qui crée réellement de la valeur. L auteur explique également l importance de la conduite du changement, qui permet non seulement de contourner de multiples écueils, mais aussi d anticiper les attentes ou les besoins non exprimés en début de parcours. Alors, la DSI pourra transformer le SI en arme stratégique et concurrentielle. Moderniser son système d information Sabine Bohnké Éditeur : Eyrolles 290 pages - environ 35 IT-expert n 88 - novemebre/décembre

42 Le Cloud Computing privé au service des métiers Le Cloud Computing est compris par nombre d observateurs comme de l outsourcing de la DSI. L infrastructure informatique de l entreprise sera hébergée chez un fournisseur qui va mettre à disposition pour la DSI des interfaces de gestion des serveurs. Le processus de création des serveurs par la DSI, le paramétrage des réseaux (VLAN), et l allocation des volumes pour le stockage se réduit à une suite d actions, sur une interface de gestion via le Web, très proche des processus utilisés sur les sites d E-Commerce. 42 IT-expert n 88 - novembre/décembre 2010

43 Rubrique à brac ette formule est rentable dans le cas où le modèle standard proposé par le fournisseur est accepté par la DSI. Dans le cas contraire, l adaptation des processus industriels du fournisseur rend la formule plus chère à la consommation. Une autre vision du Cloud Computing consiste non pas à se limiter à l outsourcing des datacenters, mais à l inscrire dans une démarche d industrialisation de la DSI qui utilise alors les technologies en émanant. Ainsi, la DSI proposera ses services d une manière automatisée et robotisée à ses clients finaux : les équipes métiers de l entreprise. Cette formule de Cloud Computing privé permet au DSI de quitter son habit de fournisseur de moyens pour endosser celui de fournisseur de services en proposant le modèle «Self Service». Le self-service IT à portée de tous Le cycle standard d un projet informatique se traduit par de nombreuses étapes étalées dans le temps, comme le montre le schéma ci-dessous. Ainsi, tout responsable d un projet dans une entreprise pourra créer une ou plusieurs plateformes, selon ses besoins et son budget, sans investissement préalable lourd. De la même manière, tout collaborateur de l entreprise pourra accéder à ses applications ou à ses outils de développements, sans obligation de les installer sur son poste de travail physique. Bien entendu, la gestion des droits d accès et d utilisation régule non seulement l usage des ressources, mais s occupe aussi de tracer toutes les actions, voire de les chiffrer financièrement, pour une éventuelle refacturation. Un confort pour le DSI et les métiers A l aide d un catalogue de service, la DSI propose les applications métiers aux utilisateurs via un site web sécurisé. Chaque utilisateur dispose d un ensemble d applications selon son profil et ses situations de travail. Ainsi, la gestion du poste de travail par la DSI sera réduite à une opération de création d un Master unique pour tous les profils, avec des variantes si nécessaire. Plus besoin de déployer les patchs applicatifs sur les postes physiques, et plus besoin de gérer la compatibilité des applications entre eux ou avec les systèmes d exploitation. On constate que la phase de démarrage des développements est conditionnée par la mise en place de la plateforme de développement, qui dépend à son tour de la phase des achats des serveurs et licences, liée elle-même à la phase de mise en œuvre de l architecture technique. Un enchaînement d étapes interdépendantes. Le délai de démarrage d une plateforme de développement est, dans un processus standard, estimé à une durée de 8 à 18 mois. Dans le cas du Cloud Computing, cette période est réduite à quelques heures. En effet, l équipe Projet se charge de la sélection et de la gestion des plateformes. Il lui suffit de commander, de dimensionner et de démarrer les plateformes, via une console de gestion proposée par la DSI. Les étapes du cycle du projet seront alors réduites, et la dynamique globale est simplifiée, comme l illustre le schéma ci-après. De même, à l aide d un entrepôt virtuel de plateformes prêtes à l emploi, la DSI propose les outils nécessaires à la gestion des serveurs de ses plateformes aux utilisateurs habilités. Les tâches standard seront ainsi prises en charge par les projets. Plus besoin de faire appel à des équipes techniques pour la mise en place de l architecture, l installation et la gestion des serveurs. IT-expert n 88 - novembre/décembre

44 On peut en déduire que : la DSI peut fournir plus de services à valeur ajoutée aux utilisateurs, et les accompagner à l aide des procédures robotisées, agiles et réactives, et gérer plus de projets avec la même équipe ; les équipes projets disposent des outils nécessaires pour maitriser et réduire les coûts de leurs projets en favorisant une mise en oeuvre plus rapide. Vers un catalogue de services La DSI maintient un portail Web à disposition des utilisateurs, et publie les applications, les services et les plateformes prêtes à l emploi, etc. Par exemple, si une équipe métier a besoin d une plateforme de développement GED, le responsable se connecte au site de catalogue de service, et choisit une plateforme de développement GED, la commande et la démarre. Cette plateforme est composée de plusieurs serveurs (annuaire, base de données, solution de GED, serveur Web ) tous installés selon les procédures standard de l entreprise, dans la bulle réseau de développement, via des processus automatisés. Si des outils de développements sont nécessaires, les développeurs n ont qu à accéder au site de catalogue de service et à lancer les outils de développements sans avoir à les installer en local. Dans cette optique, le Cloud Computing consiste à assembler un ensemble de technologies comme la virtualisation des serveurs et des applications, le SOA pour gérer les processus comme la création et la gestion des serveurs, la facturation à l utilisation, des interfaces Web pour les consoles de gestion, etc. Pour mettre en place une plateforme Cloud Computing privée en adaptant l existant, une pré-étude doit être menée afin de cartographier le SI de façon à faire le lien entre les serveurs, les applications Back-End, les applications Front-End, le degré de confidentialité de données, les applications sur les postes de travail, et de leurs usages par les utilisateurs. (cf figure ci-dessus) Une fois cette cartographie réalisée, les solutions peuvent être choisies afin de déterminer où et comment la plateforme de cloud computing doit être construite. Une fois que les choix des technologies et des fournisseurs (internes ou externes) réalisés, l étape de l industrialisation sera réalisée afin de rendre le processus de self-service opérationnel par les utilisateurs qui n ont pas de compétences techniques. Ce type de portail en «self-service» offert par les techniques du Cloud Computing autorise les DSI à proposer des services réactifs, agiles et industriels afin de faire face aux demandes des utilisateurs de l entreprise, toujours désireux d obtenir satisfaction dans les plus brefs délais. n Nicolas Koleilat, Senior Manager Agile & Collaborative Solutions Responsable de l offre Cloud Computing Acteur majeur du conseil et des services informatiques, Sopra Group a réalisé en 2009 un chiffre d affaires de 1,1 milliard d euros pour employés. Son périmètre de compétences s étend depuis la réflexion stratégique en amont, jusqu à la conduite de grands projets d intégration de systèmes et à l outsourcing applicatif. Le Groupe poursuit le déploiement mondial de son activité d intégration d applications et de gestion des processus métiers à travers sa filiale Axway, leader mondial des «Collaborative Business Solutions». Site web : 44 IT-expert n 88 - novembre/décembre 2010