75702914-esb-it-88

ITLA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE L'INFORMATIQUE

n°88

Bim

estr

iel -

no

vem

bre

/déc

emb

re 2

010

Architecture de Sécurité - coopérer pour protéger efficacement son SI

TOP5 des anti-patterns appliqués à l’ESB

Les Appliances dans les Infrastructures SOA

Les visions dynamiques de l’Architecte d’Entreprise

La gouvernance du patrimoine applicatif - optimisation de la qualité applicative

Le Cloud Computing privé au service des métiers

EditeurPress & Communication FranceUne filiale du groupe CAST3, rue Marcel Allégot92190 Meudon - FRANCETél. : 01 46 90 21 21Fax. : 01 46 90 21 20http://www.it-expertise.comEmail : [email protected]

Rédacteur en chefJosé DizEmail : [email protected]

Directeur de publicationAurélie MagniezEmail : [email protected]

Abonnements/PublicitéEmail : [email protected]

Conception GraphiqueNicolas Herlemhttp://nico.freelance.free.fr/

ParutionIT-expert - (ISSN 1961-9855) est un journal édité 6 fois par an, par P&C France, sarl de presse au capital de 60 976,61 €.

AvertissementTous droits réservés. Toute reproduction intégrale ou partielle des pages publiées dans la présente publication sans l’autori-sation écrite de l’éditeur est interdite, sauf dans les cas prévus par les articles 40 et 41 de la loi du 11 mars 1957. © 1996 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.

Abonnements01 46 90 21 21

Vous pouvez vous abonner gratuitement sur http://www.it-expertise.com/

ITLA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE L'INFORMATIQUEDélit de Pattern-IT

Avec le souci de bien faire et de faire gagner du temps, les grands cabinets de consulting industria-lisent 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é DizRédacteur en Chef

édito

4 IT-expert n°88 - novembre/décembre 2010

5IT-expert n°88 - novembre/décembre 2010

IT-expert n°88 - novembre/décembre 2010

6 DossierArchitecture 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 TechniqueLes 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 TechniqueTOP5 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 InternationalesLes 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 LivresExpression 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é.

Sommaire


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.

Architecture de SécuritéCoopérer pour protéger efficacement son SI

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.


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.

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 ad-hoc (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évolu-tionnaire, 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’Entreprise2. le processus de pilotage de la transformation3. le cadre de capacité de transformation

Principes, Vision, Exigences d’Architecture

Architecture Business Architecture des systèmesd’informations

Réalisation de l’architecture

Architecture Technique

Phases préliminaires

Exigences - Hypothèses - Ecarts

Motivation

Données

Servicesde Plateformes

ComposantsTechniques

ApplicationOrganisation

Fonction

Opportunité, Solution,Planification

Gouvernancede la réalisation

Vision d’architectureStratégie Métier - Stratégie Technique – Moteurs - Acteurs

SÉCURITÉ

SÉCURITÉ

SÉCURITÉ

Figure 1 : le référentiel d’ASE


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.

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.

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.

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.

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 non-satisfaction, 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.

Réussir la transformation

Déployer la transformation Architecturer la transformation

Gouvernerla transformation Instruire

l’architecture

Cadrer la transformation

cible

Les pointsde vueProjets de

la transformation

existant

Référentiel

Gouvernance

Structurer l’organisation – Processus – Référentiel

Développer et entretenir les compétences individuelles et collectives

Bâtir une capacité d’architecture : volet compétence

Grille de Compétences

Rôles et Responsabilités

FormationCursus

Parcours

CoachingMonitorat

Evaluation


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

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


• gestion de l’identité : réconciliation avec des sources auto-ritaires, 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 popu-

lations 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

ProcessusRéférentielsInformations

Processus

Acteurs du SI

Performance Conformité

Gérer le cycle de vie des utilisateurs et des rôles

Gérer les ressources

Contrôle d’accès

PersonnesIdentités

Fédération

Provisioning

Gestion des identités

Audit

Gérer les rôles

Gérer le risque

SécuritéSécurité

SI

Architecture

Utilisateur RH Métier RSSI

Figure 4 : la Gestion des Identités et des Accès (Source Arismore)

Dossier


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

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 : www.arismore.fr

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.

Au programme :

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.

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 ?

PROGRAMME DETAILLE ET INSCRIPTION GRATUITE :

http://www.idc.fr/strategie_sourcing2011code invitation « ITX »

ou contacter Edith [email protected] - tel. : 01.56.26.26.91

Conférence organisée par IDC

IDC, cabinet leader de conseil, et d’études

dans les technologies de l’information

en partenariat avec

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

Participez à la conférence IDC Stratégies de Sourcing le 19 janvier 2011, à Paris pour :

Définirunepolitiquedesourcingadaptéeetadaptableàlatransformationdel’entrepriseet garante de l’optimisation de l’infrastructure et des applications

Différents modèles et solutions de global sourcing

Gagner une longueur d’avance vers l’étape ultime de l’externalisation ?

Le Cloud Computing

Mesurer les enjeux et la création de valeur pour l’entreprise : réduire les coûts, gagner enflexibilitéet libérerdesressourcespour investirdansdenouveauxprojetsoudenouveaux modèle économiques

La politique de Sourcing

Bertrand ETENEAU – DSI – FaureciaYann BEYNoN – DSI – RoCHE

Gael DoMINIQUE – Direction des achats Groupe – ToTALStéphane CoRDIER – DSI – Alliance Healthcare France

Avec le retour d’expérience de :


Les Appliances dans les Infrastructures SOA

Technique


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.

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


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.

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.

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.

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.

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

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.

Web-Services Consommateurs

Externes

Appliance SOA

Appliance SOA

Web-Services Fournisseurs

SOAP/HTTP(S) SOAP/HTTP(S)


Internes

DMZ

IP F

irew

all

IP F

irew

all


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.

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.

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.


Appliance SOA

Monitoring Web-Services

Registre SOA

Web-Services Fournisseurs

SOAP/HTTP(S) SOAP/HTTP(S)

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

Technique


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

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…

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.

Appliance SOA

Appliance SOA Appliance SOA

Consommateurs

Médiations exposées

Services

Réseau

Internet

DMZ

IP F

irew

all

IP Firewall

Appliance SOA

Monitoring Services

ESB

Consommateurs

Services

SOAP/XML/REST SOAP/XML/REST

SOAP/XML/REST

Technique


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.

TOP5 des anti-patterns appliqués à l’ESB


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

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

Figure 2 : mauvais rôle fonctionnel endossé par l’ESB

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.

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’inter-

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

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

DescriptionSuite à 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.

Interfaces consommées

Expositionde Service

Application Source

AdaptationFonctionnelle(filtrage, transformation…)

Interfaces exposées

Applications CompositesPortail Externe

Registre etRéférentiel SOA

Médiation de ServicesFournisseur/ Consommateur

Référentielde Sécurité

Applications CompositesPortail Interne & Applications

Partenaires B2B Integration

Business Process Management

Exposition de ServiceExposition de Service(Enablement)Moteur d’exécution

Application ERP LegacyBusinessDatabase

BusinessDatabase

Moteur d’exécution

Interactions Utilisateurs et B2B

Infrastructures transverses

Domaine Métier 1

Fonctions portées par un ESB

Domaine Métier 2

Figure 1 : architecture logique simplifiée d’un socle SOA

Technique


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

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

CauseLeitmotiv souvent entendu « Nous avions déjà une démarche Service, il n’y a plus qu’à les exposer en Web services».

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

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

Figure 3 : typologie de service d’une démarche SOA

Anti-Pattern #3 Réplication de données

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

CauseUne vision en Silos de données, souvent issus d’une vision purement « Progicielle » ou applicative du système d’information.

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

Service Processus ServiceUtilitaire

Taux

de

réut

ilisa

tion

croi

ssan

t

Service Tâche

Service Entité

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.


Anti-Pattern #4 La multiprise

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

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

La désynchronisation des données est un risque fort, directe-ment 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.

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

Application verticale par branche métier

IHM IHM

Application composite orientée processus

Processus BPM

Domaine fonctionnelde Services

Domainede Services métier



Domaine fonctionnelde Services

Traitements

Données

Flux EAI

Diffusiond’information

Données

Traitements

Application composite multi-domaines pour processus transverses

Figure 4 : différence d’approche EAI/ESB

Technique


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

SolutionPour éviter ce type d’anti-pattern qui a des impacts tech-nologiques 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

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

CauseManque d’analyse de ses propres besoins, d’identification des exigences fonctionnelles et non fonctionnelles.

EffetL’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, surinves-tissement 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 ser-vices 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»).

SolutionLa 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 1re 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 39 000

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 : www.logica.com


Actualitésinternationales

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’e-mail 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 2008. 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


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 (12 000 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


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 2009. 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’e-mails d’avertissement, aurait-il conforté cette tendance apparente ? Rien n’est moins sûr. En effet, sur l’échantillon de 1 003 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 15-24 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


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 2 600 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

35 000 ! C’est le nombre de recrutements réalisés dans l’industrie informatique en France en 2010 (dont 26 000 cadres), contre 22 000 en 2009. Pas loin du record de 40 000 atteint en 2008. Et selon le Syntec Numérique le mouvement devrait perdurer en ce sens en 2011. Les plus dynamiques ? Les éditeurs, les SSII et les prestataires avec un total de 26 000 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 www.passinformatique.fr à destinations des étudiants, mais aussi des parents et des professeurs. n


Les visions dynamiques de l’Architecte d’Entreprise


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 celles-ci 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.

Une vision transcendant SI et processus

Objectiver les transformations

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.


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


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.

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.

Périmètre de la plateforme

Programmationdes vols

Contrôle aériende la plateforme

TraitementAvion

AssistanceContrôles

SûretéSécurité

Gestion et régulationdu trafic aérien

Intégrateur de services aux opérateurs de la chaîne de transport

Propriétaire et intégrateur des installations de la plateforme

Compagnie aérienne Entretien-maintenance-logistiqueFournisseurs et opérateursdes systèmes industriels

VolDécollage

AtterrissageAutres prestationsAutour de l'avion

DéchargementRotation

ChargementContrôles

Attributiondes ressources

Attributiondes slots

Opérateursde la plateforme

Opérateursindustriels

Intégrateur



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.

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.

Préparationdu voyage

Commerces…Agence de voyage Opérateur parking AssistanceServices

aux passagers(salons…)

Contrôles sureté,sécurité (PIF,

police…)

Superviseurdu réseau de

l'aéroport

Intégrateur de services aux opérateurs de la chaîne de transport

Propriétaire et intégrateur des installations de la plateforme

Compagnie aérienne Entretien-maintenance-logistiqueFournisseurs et opérateursdes systèmes industriels

Vol

EnregistrementEmbarquement

Débarquement,livraison bagages

ContrôleCommerces, hôtels,

restaurants…

Information,déplacement, services

aéroportuairesStationnementAcheminement

Opérateursde la plateforme

Opérateursindustriels

Intégrateur

Périmètre de la plateforme



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…

Offer Creation

Purchase Operator

Maturity

Maturity

DevelopmentMarket

VariationEnd of Life

CycleEnd of Cycle

ProductEvolution

ProductAvailability

Endof Campaign

CampaignDevelopment

Campaignbegining

CampaignDefinition

Productspecifications

New productannouncement

Product Marketing

Product Integration

Advertising Sales development

Market Analyse Service Operator

Service Operator

Integrator

Industrial Product Life Cycle Market Cycle

Market Cycle

Incident Resolution Closure Change InformationInitial

Support

Service Desk

Incident Management

Problem Management Change Management

Configuration Management

Data resource (CMDB)

Service Operator

Resource

Integrator


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

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 (www.urba-ea.org ).

Site web : http://www.oresys.eu/


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.

La gouvernance du patrimoine applicatifoptimisation de la qualité applicative

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 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, faire évoluer ou optimiser directement les applications.

Figure 2 – Quelques segments de marché de la Gouvernance applicative (Source le CXP, 2010)

GOUVERNANCE APPLICATIVE

DÉCISIONNEL ANALYSE OPTIMISATION

Figure 1 - La gouvernance applicative (Source le CXP, 2010)

Figure 2 – Quelques segments de marché de la Gouvernance applicative

Source le CXP, 2010


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.

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

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


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

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.

Analyses du code 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 9126. 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.

Tableaux de bord 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.).

Gestion des coûts applicatifs

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.

Exports, rapports et documentation

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.

Identification et traitement des erreurs

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

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

Quoi de neuf Docteur ?


Un marché très disputé

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.

Généralistes

ASGCastMcCabeMetrixwareMicro Focus

CompuwarePlanviewSerena

Checkstyle (OS)IBMMetawarePMD (OS)Polyspace

IBMCastMetrixwareMicro FocusSpeedware

Mono technologieset Open Souce

Acteurs domaineapplicatif

Acteurs PPMGest

ion

de la

qua

lité

appl

icat

ive

Gest

ion

de lp

orte

feui

lles

appl

icat

ifs

Documents CXP associésService 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 : http://www.cxp.fr/commandes/gouvernance-patrimoine-applicatif_000229/

• Etude d’opportunité• Documents à l’unité d’analyse des offres : ASG, Cast, Metrixware, Micro Focus.

Livres

41IT-expert n°88 - novemebre/décembre 2010

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 chargesYves ConstantinidisÉditeur : Eyrolles246 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 : Eyrolles290 pages - environ 35 €


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.

Le Cloud Computing privé au service des métiers

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.

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.

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.

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.


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 12 000 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 : www.sopragroup.com