Article paru dans la newsletter #20 – Ete 2007

Le 1er juin, a eu lieu à La Défense un séminaire IBM sur la SOA. Big Blue n’a pas lésiné sur les moyens et nous a offert un grand show sur l’état de l’art en matière de SOA.

Le séminaire a commencé par une réunion plénière sur la SOA en général et, en particulier, sur la façon de la mettre en œuvre chez nos clients. Le discours était conforme à notre démarche Think Service et aux conclusions que nous avons pu tirer à partir de nos propres expériences :

• La SOA contribue à l’architecture globale d’entreprise et, à ce titre, participe à l’urbanisation des systèmes d’information.
• L’identification des services doit être faite à partir des processus métier et des blocs fonctionnels.
• …

Depuis que la SOA a émergé en 2005 dans le monde des télécoms, son essor se confirme : tous les domaines sont maintenant demandeurs, pour lesquels la SOA est en mesure de répondre à des besoins technologiques et/ou fonctionnels.
Des témoignages d’IBM, d’éditeurs et d’intégrateurs nous ont fait bénéficier de plusieurs retours sur expérience constituant autant de facteurs clés de réussite de la SOA :

• Pour qu’un projet SOA d’entreprise réussisse, il est nécessaire que ce projet ait un sponsor haut placé dans la hiérarchie et susceptible de briser les silos, anticiper les besoins de nouveaux projets et préconiser voire imposer les changements organisationnels appropriés.
• Un projet SOA d’entreprise commence par un projet pilote dont l’objectif est d’établir un « proof-of-concept » et de définir les bénéfices attendus, en termes de supervision des processus, réutilisation des services…
• Il faut ensuite mettre en œuvre un socle SOA transverse constitué de toutes les briques techniques nécessaires (plates-formes, ESB, moteur d’orchestration…)
• Le déploiement de la SOA doit alors être préparé et organisé et doit établir des guides méthodologiques sur les procédures de mise en œuvre, sur les procédures de mise en exploitation mais également sur des sujets se rapportant à la gouvernance SOA (qui est le propriétaire d’un service? Qui paie pour les évolutions à apporter à un service? Qui est le propriétaire d’une donnée ?)
• S’appuyant sur ce socle SOA transverse, le déploiement de la SOA adresse ensuite successivement tout ou partie des métiers de l’entreprise.

Au titre de ces retours sur expérience, l’accent a été mis sur l’information, terme noble employé pour désigner les données qui sont stockées ou qui transitent dans les systèmes informatiques. IBM a insisté sur la nécessité de maîtriser l’information dans ses différentes composantes :

• Composante technique : Dans quelle(s) base(s) de données une information est-elle rangée ? Quelle application est propriétaire d’une information ?
• Composante syntaxique : Quelle est la structure de l’information ?
• Composante sémantique : Quel est le sens attribué à une information ?

Il est fondamental que toutes les parties prenantes s’entendent sur toutes ces acceptions. C’est pourquoi IBM nous invite à nous focaliser sur :

• La compréhension sémantique des informations. De nombreuses « ontologies » voient le jour en ce moment, de façon à décrire le sens métier porté par les données.
• La qualité de service requise pour la gestion et l’accès à une donnée : temps de réponse maximum, fiabilité de l’information…

Le séminaire s’est poursuivi par plusieurs ateliers.

Atelier « Méthode SOMA »

Cet atelier avait pour objectif de présenter SOMA (Service Oriented Modeling and Architecture), la méthode IBM d’identification des services.
Cette méthode préconise de procéder en plusieurs étapes :

• Identification des services candidats, à partir des processus métier et d’une analyse des services et applications déjà existants.
• Définition, à grosses mailles, des spécifications des services : entrées/sorties, périmètre fonctionnel, qualité de service…
• Prospection sur la réalisation : faisabilité technique, découpage en composants…

Cette méthode procède par itérations successives, de manière à affiner et consolider l’identification des services effectuée à chaque itération.
Le retour sur expérience acquis par IBM sur cette méthode nous invite à surveiller particulièrement les points suivants :

• Services alignés sur les processus métier.
• Services réutilisables.
• Granularité des services.
• Services non redondants.
• Opérations de service non interruptibles.
• Services sans état fonctionnel.
• Encapsulation des services.
• Qualité de service.

Atelier « Gouvernance SOA »

Si une entreprise ne prend pas les dispositions pour établir des règles de gouvernance SOA, la SOA mise en œuvre risque d’être victime de son succès : incapacité à gérer une montée en charge des utilisateurs, budgets non prévus pour les évolutions fonctionnelles à apporter aux services mis en exploitation ou pour le renouvellement de l’infrastructure logicielle ou matérielle…
Il faut en effet considérer que le SI n’évolue plus seulement au rythme des projets d’évolution partielle ou totale : la SOA amène le SI à évoluer en permanence, de manière flexible. Derrière ces nouvelles capacités du SI, résident des enjeux se rapportant à l’intégration plus rapide des nouveaux composants, à la réduction du « time-to-market », à l’amélioration des relations entre les utilisateurs internes ou externes des applications et les projets de maintenance…
C’est pourquoi il est fondamental de se poser les questions suivantes, pour continuer à tirer les bénéfices d’un « proof-of-concept » SOA réussi et pour être en mesure de déployer la SOA :

• Y a-t-il un sponsor SOA ?
• Quelle est la vision SOA de l’entreprise ?
• Des contrats ont-ils été établis entre les producteurs et les consommateurs de services ?
• Quel est le cycle de vie d’un service ?
• Quelles sont les différentes qualités de service proposées aux consommateurs de services ?
• Quel est le modèle de financement des services ?
• Quel est le modèle de propriété des services ?

Ces questions tournent toutes autour de la gouvernance SOA qui consiste à définir les points suivants :

• Rôles et responsabilités de toutes les parties prenantes.
• Principes SOA techniques et métier retenus au niveau de l’entreprise.
• Architecture fonctionnelle et technique réajustée en permanence.
• Infrastructure.
• Portefeuille de services.
• Modèle de financement des services.
• Sensibilisation et accompagnement des projets.
• …

IBM nous conseille de mettre en place un centre d’expertise (ou centre d’excellence) susceptible de réfléchir à tous ces sujets, trouver des compromis, y apporter des réponses de manière collégiale et vérifier que les dispositions retenues sont appliquées effectivement.

Atelier « SOA et MDM »

Cet atelier avait pour objectif de partager un retour sur expérience d’une mission effectuer à Orange. Face à des applications et des bases de données multiples, hétérogènes et construites sur des modèles de données différents, le besoin consistait en une réconciliation sémantique des données.
S’appuyant sur une très belle citation d’Albert Camus (« Comprendre, c’est avant tout unifier », cf. Le mythe de Sisyphe), un partenariat IBM-Orange a cherché à remettre les données au centre des préoccupations, dans une approche de type intégration de bas en haut.

Au final, une solution technique a été mise en œuvre, notamment à l’aide de l’outil Rational Data Architect, et a permis de :

• Collecter toutes les sources de données, avec leurs méta-données et leurs règles métier.
• Constituer un méta-modèle universel.
• Mettre à jour en temps réel le méta-modèle lors des évolutions apportées aux différentes sources de données.
• Mettre à la disposition de la cellule transverse en charge de la réconciliation des données, une application permettant de suivre les associations opportunes entre sources de données.

Atelier « Mise en exploitation des architectures SOA »

Cet atelier avait pour objectif de décrire les différents sujets à surveiller lorsqu’une application conforme à une architecture SOA est mise en production :

• Suivi des contrats de service.
• Gestion des incidents.
• Suivi des capacités, ne serait-ce que pour la montée en charge des utilisateurs.
• Suivi des besoins non fonctionnels : continuité de service, sécurité…

IBM propose une méthode assez classique dérivée d’ITIL qui consiste à :

• Etablir une typologie des applications et des services.
• Interviewer les parties prenantes de la mise en exploitation, de façon à apprécier le niveau de leurs connaissances fonctionnelles et de leurs compétences techniques.
• Etablir un « radar » où, sur plusieurs axes, sont mesurés différents indicateurs.
• A partir du radar, établir un plan de transformation.

En particulier, le retour d’expérience d’IBM sur ce type d’intervention nous invite à analyser l’impact des architectures SOA sur les procédures d’exploitation.

Ainsi, on aura les moyens de :

• Mesurer et garantir la qualité de services des architectures SOA :
  • Taux de disponibilité (ex : 99%).
  • Temps de réponse (ex : 2 ms).
  • Sécurité : cryptage, non répudiation…
  • Exploitabilité : gestion des capacités, gestion des incidents…
• Superviser le SI au moyen d’indicateurs :
  • Processus métier : performances métier, flux de données, BAM.
  • Services : gestion contractuelle des SLA, performances applicatives.
  • Infrastructure : système et matériel.

Atelier « SOA et Web 2.0»

IBM nous a montré dans quelle mesure l’association de ces deux mots à la mode peut avoir du sens.
IBM a brièvement rappelé les grands principes du Web 2.0 :

• Dimension communauté :
  • Communauté d’utilisateurs (réseaux sociaux).
  • Recommandations des informations publiées.
  • Interactions possibles entre acteurs, de façon à créer de la valeur en plus du contenu publié.
• Dimension architecture :
  • IHM avancées (Ajax).
  • Flux de données (Atom, RSS).
  • Composition d’application par assemblages (Mashup).

IBM se positionne sur le Web 2.0, de façon à permettre l’accès à toutes sortes d’informations (blogs, flux RSS, activités Notes, Wiki…), au moyen d’onglets mis en œuvre sur des interfaces unifiées (blackberry, Windows Explorer, Notes V8…).
Quel rapport avec la SOA ? SOA et Web 2.0 considèrent les logiciels comme des services susceptibles d’être assemblés. Et si les technologies Web 2.0 nous permettent de composer facilement des applications à partir de web services, la SOA répond à un besoin d’urbanisation, ne serait-ce que pour promouvoir des normes et des standards (WSDL, BPEL, WS-Security…) et continuer à savoir répondre à plusieurs questions cruciales : à qui appartient telle donnée ?, à qui appartient tel service ?, quel est le sens de telle donnée ?…

Eric Suignard

Tags: Conférences, SOA

This entry was posted on Thursday, June 28th, 2007 at 4:15 pm and is filed under Intégration. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.