SOA, UCC, Web 2.0 : Les nouveaux enjeux de votre entreprise

Je suis en train de préparer une présentation pour le Forum SOA sur le thème SOA, UCC, Web 2.0 les nouveaux enjeux de l'entreprise de service .

Aujourd'hui, les applications composites développés avec sur une infrastructure de services SOA doivent être complétés avec les services de communication et collaboration (les solutions unified communication and collaboration) et les services du Web 2.0 et des réseaux sociaux. Ces trois domaines technologies convergent et l’intégration des fonctions de communication et de collaboration directement dans les applications composites, offre un support aux collaborateurs dans toutes les facettes de son travail quotidien : du travail sur les processus formels aux interactions libres, des collaborations structurés aux échanges informels, du traitement des données qualifiées de l’entreprise à la découverte d’informations disponibles sur Internet.
Basées sur des technologies communes (XML, Web Services, TCP/IP), ces nouvelles "technologies" augmentent le champs d'action de la DSI.

• La technologie s'efface derrière les métiers. Le matériel disparait avec la virtualisation et le cloud computing, le logiciel et en particulier le middleware disparait avec les SOA, et les applications traditionnelles s'effacent avec de nouveaux modèles (SaaS, ESOA, Fusion...)
• Les ressources informatiques deviennent illimités. Des plateformes additionnelles viennent complémenter le traditionnel Data Center (Amazon, eBay, Youtube) . Des composants applicatifs peuvent être ajoutés aux applications traditionnelles ou sur le portail (AppExchange, Yahoo Galery, Google Gadget...)
  
• Les ressources deviennent disponibles partout (support des mobiles) et tout le temps, c'est à dire même pas connecté sur le réseau (RIA, Google Gears)
  

De plus, ces "nouvelles applications" offrent à l'utilisateur l'ensemble des services dans son contexte de travail, quelque soit le média utilisé et le terminal.
Cela permet de faire tomber un certain nombre de barrières :

• Celle de la compétence technologique avec des outils simples de personnalisation (à la Netvibes) et de composition (Widgets) permettent à l'utilisateur non-informaticien de créer ses propres applications.
• la barrière géographique en rendant les échanges avec les autres possibles ou qu'ils soient et tout le temps (Présentiel, Online Conference, Messagerie Instantanée, Wikis,...).
• la barrière organisationnelle en cassant les limites de l'entreprise pour y ajouter les partenaires, les fournisseurs et les clients (L'intégration des processus est obtenue par SOA, celle des échanges par les réseaux sociaux)

Libellés : Collaboration, Communauté, Communication, Enterprise 2.0, SOA

posted by JEMM research @ 18:18 0 comments permalink

Ilog et IBM

Aujourd'hui, IBM a annoncé qu'il projette d'acquérir ILOG l'éditeur français de logiciels.
Le projet d'accord prévoit un rachat pour un montant de 215 millions d'euros, soit une prime de 37% par rapport au dernier cours de clôture.
Fondée en 1987, par deux chercheurs de l'INRIA, ILOG propose des "systèmes de gestion de règles métier" (BRMS), une technologie d'automatisation et de partage d’un ensemble de règles pour toutes les applications de l'entreprise. ILOG fournit également des composants logiciels d'"optimisation" (plannings par exemple) et de "visualisation" (graphiques), domaines dans lesquels elle revendique la place de numéro un mondial.
Quelques commentaires :

• Pour IBM, cette acquisition constituera une belle opération en renforcant son offre BPM et SOA, autour de WebSphere.
• Pour ILOG, l'alliance avec un de ses plus gros partenaire historique permettra d'accélérer la pénétration de ses solutions. A titre indicatif ILOG (850 employés) est présent dans 30 pays là ou IBM (356 000 employés) est présent dans 170 pays.
  
• C'est également la reconnaissance qu'aujourd'hui la SOA inclue naturellement la gestion des processus métier (BPM) et, donc, de leur règles (BRM).

Enfin, c'est également le constat que l'industrie du logiciel français excelle mais ne peut survivre toute seule. Rappelons nous : "2007, année de la consolidation ... Jamais l’industrie du logiciel Français n’avait connu telle consolidation. 7 éditeurs parmi les 50 premiers (dont le n°2
Business Objects) avaient été rachetés par des sociétés étrangères". A quand le tour pour Dassault System, Axway ?
MàJ Septembre 08 : Le 4ième éditeur GL Trade vient de se faire racheter par SunGard

Libellés : consolidation, SOA

posted by JEMM research @ 17:54 0 comments permalink

Le collaborateur : utilisateur et acteur d’innovation

L'innovation du collaborateur est supportée par les approches et architectures orientées services d'une part, et par ces nouvelles technologies sociales d'autre part. D'une manière schématique, on peut distinguer les deux rôles du collaborateur : utilisateur d'innovation et acteur d'innovation

• Le collaborateur-utilisateur d'innovation est le professionnel efficacequi utilise les moyens flexibles et adaptés d'exécution de processus dynamiques, de collaboration avec l'ensemble des participants du domaine et de gestion de l'information. Les applications composites, basées surles architectures orientées services, facilitent son travail. Elles le guident dans la partie formelle et structurée de son activité dans le cadre de l'entreprise, elles le supportent dans l'exécution des processus, elles facilitent sa collaboration avec tous les participants de l'entité, elles lui apportent et présentent les informations nécessaires à la compréhension de son environnement. C'est la démarche top-down du travail, guidée par l'entreprise. Le rôle et la responsabilité du collaborateur sont définis par le manager.
  
• Par contre, dans une démarche bottom-up, le collaborateur-acteur d'innovation agit dans un environnement qui n'est pas structuré par l'entreprise, mais au contraire adapté à ses besoins propres et présentés selon sa logique. Au-delà de ses tâches formalisées,
  qualifiées et structurées, le collaborateur peut ainsi agir de manière beaucoup plus libre, inventer et valider des nouveaux modes opératoires, tester de nouvelles collaborations, connaître les spécialistes qui peuvent l'aider dans l'exécution de ses tâches, et découvrir ou
  manipuler de l'information en provenance de sources diverses. C'est le nouvel écosystème du collaborateur et de sa communauté. Les nouvelles technologies collaboratives supportent cette dimension du collaborateur-acteur d'innovation. Blogs, wikis, tags, annuaire d'expertise, messagerie instantanée sont autant de moyens qui permettent d'accompagner le collaborateur dans sa recherche d'innovation et de collaboration avec les personnes qui sont au-delà de son cercle direct de relations professionnelles.
  

Libellés : Collaboration, SOA, Web 2.0

posted by JEMM research @ 18:57 0 comments permalink

Consolidation, consolidation

Encore une nouvelle qui conforte les trois tendances du monde SOA... Progress Software va racheter Iona Technologies.

• La consolidation est en marche. Plus médiatisé chez les grands acteurs (Oracle et BEA, IBM et Cognos, SAP et B.O,...) elle touche aussi les acteurs de "niches" spécialisés sur un des aspects de l'infrastructure (ici un spécialiste du bus rachète un expert d'infrastructure applicative basée sur Corba).
• La banalisation de middleware est inéluctable. Pour survivre, les acteurs doivent atteindre une taille critique (On se rappelle Software AG et WebMethods), offrir une palette complète ou une expertise spécialisée (le bus de message) et une couverture mondiale (ici c'est un acteur américain qui rachète un acteur européen)
• La standardisation est obligatoire. La technologie d'intégration Corba est peut-être performante mais reste limitée aux environnements....Corba, là ou les standards (XML, Web Services, REST..) n'imposent qu'une syntaxe et un sémantique commune aux messages échangés.

Libellés : consolidation, progress, SOA

posted by JEMM research @ 13:01 0 comments permalink

Approche et Architecture orientées Services (Etude AMR)

Le cabinet d'analyse AMR Research vient de publier une enquête "The SOA Spending Report 2007-2008" .
D'après 405 DSI basés aux Etats Unis, Allemagne et Chine, les raisons d'investissement dans une SOA sont multiples, en particulier de

• Répondre d'une manière rapide, économique, et en limitant les risques aux besoins de changement (21%)
• Répondre à des projets individuels (18%)
• Réduire les coûts IT grâce à la réutilisation (17%)

SOA coute cher. 45% des clients ont dépensé plus de $500K en logiciels et services SOA en 2007 (67% pour les services financiers).
Dans un interview à Infoworld, l'analyste de AMR fait la différence entre les avantages "vendus" par les éditeurs de logiciels (la réutilisation) et la réalité dans les organisation (l'amélioration de l'agilité).

Commentaires
Sur ce dernier point, je suis complètement d'accord.
Si le A de SOA ne signifie qu'Architecture, les avantages de cette inititative resteront limités au niveau de la DSI et à la technologie.
Si le A de SOA signifie Approche, alors l'organisation dans son ensemble peut appliquer un approche orienté service.
L'approche Orientée Service peut être appliqué sans tenir compte de la technologie. Dans ce contexte, les but de l'approche sont :

• faciliter l'intégration entre des entités métier
• permettre la réutilisation d'actifs métiers
• réduire les coûts métiers
• créer des ponts entre les métiers

Par quels moyens ? L'approche orienté service consiste à envisager des services métiers qui sont

• Adaptatifs au au contexte
  
• Basés sur un modèle de couplage lâche
• Basés sur un contrat et des points d'accès
  
• Basés sur un modèle de relations standards

Les deux grands sujets de l'approche orientée service restent la gouvernance pour organiser les relations entre ces services et bien sur les finances (qui paye pour quoi)

Libellés : Approche, Architecture, SOA

posted by JEMM research @ 10:25 1 comments permalink

Une SOA clé en main ?

Un post en anglais intéressant sur le blog de Judith Hurwitz (Cabinet d'analyste Hurwitz & Associates).
Judith explique que l'architecture orientée service ne peut s'acheter clé en main comme un programme de gestion intégrée (PGI - ERP) ou un environnement de gestion de la relation client (GRC - CRM).
Et pourtant, les grands vendeurs, comme IBM, SAP, Oracle/BEA clament le contraire en proposant un stack complet d'infrastructure et d'applications SOA.

D'après Judith, SOA est une architecture et une méthodologie, on ne peut donc pas la trouver dans un seul produit. Ensuite l'objectif même de SOA est de créer une infrastructure modulaire capable d'ajouter ou de retirer des composants supportant une nouvelle initiative métier ou ou nouvelle technologie. Enfin le meilleur itinéraire pour SOA est de commencer "petit" sans pour cela investir dans une toute l'infrastructure.

Quelques commentaires

• Faire confiance à un seul éditeur facilite la mise en oeuvre d'un environnement agile dans le cadre proposé par l'éditeur. C'est lui qui s'occupe de l'intégration de l'infrastructure et des applications et règle les problèmes d'intégration et d'interopérabilité entre les silos (lliens entre l'orchestration des services et le bus de messages, entre les services métiers et les services d'infrastructure, problèmes de sécurité). L'entreprise peut se consacrer à la définition et la réalisation des applications composites pour supporter ses processus métiers.
• C'est à la frontière entre deux environnements que les problèmes apparaissent. Il est d'ailleurs intéressant de questionner les différents éditeurs sur ce sujet. La réponse est toujours la même : tous les problèmes disparaissent si vous intégrez à partir du stack de l'éditeur. SOA tente d'apporter une réponse aux problèmes d'intégration et d'interopérabilité entre les silos applicatifs. Le mécanisme d'abstraction de l'implémentation des services, la publication des interfaces et des contrats, le respects des standards donnent des réponses simples et concrètes aux problèmes d'intégration.
• Mettre tous ses investissements dans le panier de l'éditeur nécessite l'acceptation d'une infrastructure intégrée au détriment de composants spécialisés plus efficaces. En faisant l'analogie avec le monde du hardware, un PC DELL présente un bon compromis couts vs. investissements. Par contre, l'achat et l'assemblage de composants spécialisés permet de se construire une machine ultra-performante pour faire de la CAO.
  

Il faut espérer que demain (ou après demain) le marché de la SOA aura suffisamment évolué pour offrir un ensemble de services technologiques, d'infrastructure et de services métiers fonctionnels qui permette, de créer des services métiers en ligne avec les besoins des clients. En cas d'évolution dans la stratégie métier de l'entreprise, de nouveaux besoins prioritaires des utilisateurs, d'évolution technologique majeure, il suffira de remplacer un service par sa version améliorée ou un service d'un autre fournisseur.

Libellés : interopérabilité, SOA

posted by JEMM research @ 19:20 0 comments permalink

Transformation de l’industrie de l’édition du logiciel

L'industrie de l'édition du logiciel est en train de se transformer.

• Dans le mode silo historique, les entreprises entretenaient des grandes équipes de développement pour construire et mettre au point des applications spécifiques à leurs besoins.
  
• Puis avec la venue des PGI, les entreprises ont achetés des solutions pré packagées et ont adaptés leurs structures internes pour entrer dans le modèle du PGI.
  
• Aujourd’hui avec l’apparition des SOAs, on se dirige vers un modèle de composition ou la création des « applications » se fera par assemblages de composants, les uns très spécifiques développés en interne, les autres proposés par les éditeurs spécialisés, et enfin les derniers découverts et accédés dynamiquement sur le Web.
  

Cela a quelques conséquences sur cette industrie:

• Comme Salesforce.com, les éditeurs proposant des solutions hébergés et disponibles directement sur le Web (Software as a Service – SaaS) vont devenir de plus en plus nombreuses.
  
• Le modèle historique de licence que l’on connaît aujourd’hui— Achat tous les deux ans d’une nouvelle version du progiciel, abonnement annuel de maintenance— est ébranlé par d’autres modes de commercialisation (à la consommation, au chiffre d’affaire généré, aux nombre d’entités gérées) et le modèle de l’industrie du logiciel libre.
  
• Enfin, le Web 2.0, le nouveau concept à la mode, qui regroupe un certain nombre de tendances, va probablement accélérer la transformation de l’industrie.
  

Libellés : SOA, Web 2.0

posted by JEMM research @ 18:49 0 comments permalink

Rumeurs, Rumeurs

Après WebMethods racheté par Software AG, BEA sujet à une OPA hostile de la part d'Oracle, c'est au tour de Tibco d'être au centre des rumeurs.
Son CEO, Vivek Ranadive, a déclaré vendredi qu'il fera "ce qu'il faut pour l'intérêt des actionnaires s'il recevait une offre d'achat." Tibco "est une société très attrayante" .
Vivek n'a pas confirmé si il y avait des acheteurs potentiels ou si des discussions étaient en cours. Après cette déclaration, le prix de l'action a augmenté de 5%.

Quelques commentaires

• Dans ce marché en forte consolidation, il semble inéluctable que Tibco ne peut garder son indépendance et va se rapprocher d'un écosystème
• Ici encore, IBM et HP seraient les sociétés les plus à même d'exploiter les actifs de Tibco. Des analystes ajoutent Sun Microsystems ou EMC.
  

Libellés : consolidation, HP, IBM, SOA, TIBCO

posted by JEMM research @ 11:00 0 comments permalink

Ou en est-on avec SOA?

Hier SOA était un must pour toute organisation raisonnable. Après une période faste ou toutes les nouvelles du front SOA étaient bonnes, voila aujourd'hui la phase de désillusions sur SOA.

Une enquête récente de Nucleus Research montre que SOA n'est pas la panacée des projets informatiques. Seul 37% des entreprises ayant mis en oeuvre un projet SOA ont obtenu un ROI positif. L'enquête montre également que, malgré l'amélioration de la productivité des programmeurs, les entreprises vont rarement au delà du premier projet. De plus les projets restent au niveau départemental, rarement au niveau de l'entreprise. Les barrières identifiées sont culturelles (les développeurs ne veulent pas réutiliser du code créé par d'autres), la formation insuffisante des développeurs , et le prix de l'infrastructure nécessaire (repositories/registries)

Cette enquête, très orientée Développement, amène un certain nombre de remarques:

• l'initiative SOA est une initiative de long terme et le ROI SOA (réutilisation, interopérabilité, flexibilité, agilité, ...) ne peut être obtenu immédiatement. Par exemple, le programme de réutilisation ne devient performant qu'à partir du moment ou il y a des composants à réutiliser.
  
• Beaucoup d'entreprises sont encore dans une phase d'apprentissage et commencent leur voyage SOA par des projets de taille limitée. Elles évitent ainsi et à bon escient les approches big bang.
  
• L'implémentation d'une organisation et architecture à services partagés doit combiner une démarche informatique et une démarche organisationnelle alignées sur la stratégie de l'entreprise.
  

Libellés : SOA

posted by JEMM research @ 18:56 0 comments permalink

De l'importance du langage commun

Dans le cadre d'un projet SOA, il est primordial de s'attacher à la création d'un langage métier commun entre les métiers et l'informatique. C'est la clé de l’agilité. Au delà de l'amélioration des outils d'infrastructure ou de l’ajout de nouvelles fonctions évolués dans un PGI, c'est la définition de ce langage qui permet l'adaptation rapide des processus et donc une plus grande réactivité des entreprises aux changements. Ce langage commun doit être utilisable entre l'informatique et les métiers mais aussi entre l'entreprise et ses fournisseurs informatiques, l’entreprise et son écosystème (partenaires, clients).

Il est également intéressant de noter que les éditeurs de progiciels, les éditeurs d’infrastructure et les intégrateurs se rejoignent sur cette nécessité.

• Chez les Editeurs de Progiciels

Les éditeurs de progiciels, comme SAP ou Oracle, sont bien placé pour aborder la sémantique métier. Ils développent une stratégie double : d'un coté continuer leur investissements dans la définition de processus fonctionnels communs et du langage métier associé (dans une approche transverse (HR, Finance, ...) ou verticale (Automobile, Pétrole,...), de l'autre promouvoir une infrastructure qui permette de supporter des processus particuliers par composition facile des services. Avec cette approche, les éditeurs de PGI tentent de contrôler l'ouverture de leurs progiciels intégrés (une boite noire) vers une architecture de services ou un service est remplaçable à la volée par un service concurrent. Ils proposent une infrastructure qui permet d'intégrer des composants externes en respectant l'existant. Par exemple, un DRH pourra facilement intégrer un module de recrutement externe à l'environnement HCM de l’ERP.
Pour les entreprises qui ont lourdement investi dans la mise en place d’un ERP et qui n'envisagent qu'une évolution progressive sur la base de leurs investissements actuels, cette approche est séduisante.

• Chez les Editeurs d'Infrastructure

De l'autre coté de la barrière, les fournisseurs de solutions d'infrastructure (IBM, BEA, Tibco,...) défendent une approche inverse. Ils fournissent l'ensemble des services d'infrastructure qui permet de supporter les processus métier de l'entreprise. Les services proposés supporte une intégration à tous les niveaux- le bus d'entreprise, les meta data, l'interface utilisateur, l'orchestration des services. Capitalisant sur des expériences dans les domaines applicatifs, ces éditeurs se spécialisent dans des industries (IBM et la banque, Tibco et les utilities, BEA et les telcos,...) et proposent des services et des composants plus adaptés au domaine et répondant directement aux préoccupations spécifiques des clients industrie (réduction du churn des clients telco, vue unique du client bancaire, gestion du risque pour les clients utilities).
Ici, cette approche est séduisante pour les entreprises qui ont investie dans une solution d'infrastructure et qui envisage une évolution progressive sur cette base.

• Chez les Intégrateurs

C’est peut-être les intégrateurs qui courent le plus grand risque dans cette évolution. Historiquement, les intégrateurs ont vendu des forces techniques capables de programmer et mettre en œuvre des logiciels techniques (langages, base de données, EAI,…). SOA chamboule cet équilibre. La demande des clients évolue vers un plus grand support de leur processus et une plus grande connaissance de leur métier. Les bataillons de développeurs à tout faire des sociétés de services vont devoir évoluer en des équipes commando, spécialistes de l’implémentation des règles de Bâle II dans un système d’information bancaire ou du dossier médical unique dans la branche santé. Cette évolution pose quelques problèmes car à la différence des éditeurs, les intégrateurs doivent jongler entre la connaissance des solutions des fournisseurs et le domaine du client et ses spécificités.

Libellés : SOA

posted by JEMM research @ 18:43 0 comments permalink

Quels sont les principes de SOA?

Voici quelques principes d’architecture de SOA

• Abstraction : Au delà de ce qui est décrit dans le contrat, le service cache sa logique interne au monde extérieur
• Couplage lâche : Les dépendances entre services sont minimales. La seule contrainte est de maintenir la connaissance de chacun
• Contrat : Le service adhère à un ensemble de règles de communication définies dans un document de description du service
• Composition : Des ensembles de services peuvent être coordonnés et assemblés pour former un service composite
• Réutilisation :La logique métier est répartie dans les services dans l’intention de promouvoir la réutilisation
• Autonomie : Le service contrôle la logique métier qu’il contient
• Gestion du Contexte (stateless) : Le service ne gère pas le contexte. Les appels d’un service sont indépendants. Ils ne dépendent pas d’un appel précédent
• Découverte : Le service est conçu pour être découvert et accédé au travers de mécanismes de découverte (annuaire). L’annuaire gère une description de ses capacités.

Libellés : SOA

posted by JEMM research @ 12:28 0 comments permalink

Quelle est la signification de SOA?

La signifiation "officielle" de SOA : Service Oriented Architecture, pour architecture orientée services. Une définition IT pour des spécialistes IT qui traduit l'évolution des architectures, techniques et standards de l'édition des logiciels vers un modèle similaire à celui de la fabrication du matériel. " Fabriquer une application" se fait dans le modèle SOA à base d'assemblage (éventuellement dynamique) de composants, les uns développés spécifiquement par l'entreprise, les autres en provenance du fournisseur, et d'autres enfin découverts sur Internet.
L' avantage de cette architecture est la flexibilité de la composition grâce aux composants réutilisables et le langage commun standard de communication.

On peut aussi parler de Service Oriented Approach, pour approche orientée service, c'est à dire la version métier de SOA. Ici, c'est la mise en oeuvre d'une organisation qui permette de supporter la stratégie de l'entreprise dans son environnement (concurrence, règlementation, marché, ...) en exploitant au mieux les actifs de de l'entreprise (personnel, organisation, informations, processus, etc.)
L'avantage de cette approche est l'agilité de l'organisation qui offre une structure souple et adaptable rapidement aux changements.

Il est clair que l'une (l'approche) ne va pas sans l'autre (architecture)

Libellés : SOA

posted by JEMM research @ 17:46 0 comments permalink

Ma définition de SOA

Commencons par le début : Une petite définition de SOA

1. D'abord le fameux TLA (three letter acronym) nécessaire pour monter l'importance de la chose TLA : SOA : Service-oriented Architecture
2. Ensuite pour les francophones (peut on vraiment faire de l'informatique sans notions d'anglais ou de globish ?) > SOA : Architecture Orientés Services
   

Maintenant, une exégèse sur la signification de ce TLA

• Service

Wikipedia donne une définition qui introduit la notion importante de marché avec ses entités qui produisent ou achètent
Un service est une action effectuée par une entité, (personne physique ou morale, entreprise, machine, programme) pour le bien d'une autre, avec ou sans contrepartie.On dit rendre un service.Le terme service à donc un très large champ d'application
Dans le domaine économique, la notion s'étend au marché avec des producteurs et des consommateurs de ces services.
En économie, un service, appelé aussi bien immatériel est un bien dont la production et la consommation sont réalisées simultanément

• Architecture

Wikipedia me donne une définition assez satisfaisante :

désigne une discipline qui associe art et science et qui est celle de l'architecte. Cette discipline concerne la conception et la construction d'espaces (que ce soient des villes, des bâtiments, des intérieurs, des paysages, du mobilier, des objets, des espaces virtuels...).
et par extension
le terme est utilisé pour désigner la conception ou l'acte de concevoir des systèmes d'objets complexes, par exemple architecture de système informatiques

• orientée

la je sèche.... Y a t il une différence entre architecture de services et architecture orientés services ? La SOA est-elle une architecture qui permet, un peu mais pas totalement, de concevoir un environnement (marché? ) de service ? Ou alors les services ne seraient pas des vrais services mais des choses qui ressemblent à des services ? On peut aussi considérer que ce terme "orienté", du fait de l'imprécision qu'il apporte, est le plus important. Il laisse la porte ouverte à redéfinir le TLA. Ce que tous les experts se sont amusé à faire.

A mon tour de donner MA définition. En reprenant les définitions de services et architecture, je propose

Un principe d'organisation d'un marché de services

Libellés : SOA

posted by JEMM research @ 18:50 0 comments permalink