Flux RSS
Urbanisation et SOA
282 documents trouvés, affichage des résultats 111 à 120.
| < Les 10 documents précédents | Les 10 documents suivants > |
(28/07/2008 17:39:45)
Rachat d'Ilog par IBM : les deux entreprises commentent
IBM a annoncé ce matin son intention d'acquérir l'éditeur français Ilog. Le président d'IBM France, Daniel Chaffraix a commenté ce projet de rachat pour LeMondeInformatique.fr. Jean-François Abramatic, Vice-président Chief Product Officer d'Ilog et Nicolas Robbe, Vice-président marketing produit de l'éditeur ont également donné leur point de vue à la rédaction. Cette acquisition, si elle est validée par les autorités compétentes, offrira à IBM un éventail technologique performant en complément de sa propre offre de SOA, de BPM et de gestion des règles métier. L'opération devra encore attendre les diverses validations réglementaires afférentes à toute acquisition. (...)
(28/07/2008 09:47:59)IBM projette de racheter Ilog
Dans un communiqué du 28 juillet publié par IBM et Ilog, Big Blue annonce son projet de racheter l'éditeur français. Le conseil d'administration de ce dernier a déjà donné son accord. IBM continue ainsi de se renforcer dans la SOA, le BPM (gestion de processus métiers) sans oublier la spécificité d'Ilog, la gestion des règles métier (BRMS). Après l'acquisition l'an dernier de Business Objects par SAP, c'est un autre grand et un autre vétéran du logiciel français qui disparaît hors de l'Hexagone. En dehors de Dassault Systèmes avec un CA de 1,2 Md€ et de quelques SSII, la plupart des éditeurs français (voir classement Truffle 100) se situent désormais sous la barre de 100 M€. IBM va déposer des offres publiques en France et aux Etats-Unis au prix de 10 € par action, soit un prix total maximum d'environ 215 M€. Celles-ci sont bien entendu conditionnées à l'obtention des autorisations des autorités de la concurrence européenne et américaine. Elles sont également soumises à un seuil de renonciation de 66,67% du capital et des droits de vote d'Ilog sur une base totalement diluée. (...)
(22/07/2008 11:09:19)Les 10 causes d'échec des projets SOA listées par CIO.com
Pour quelles raisons certaines initiatives SOA conduisent-elles à des projets ratés ? La mauvaise compréhension des gens impliqués, répond Mike Kavis, journaliste de CIO.com, dans un éditorial (*CIO.com est édité par IDG, actionnaire d'IT News Info, éditeur de LeMondeInformatique.fr). Suite à une discussion par blogs interposés entre plusieurs experts du sujet, dont les analystes de Zapthink Ron Schmelzer et de Burton Group Anne Thomas Manes, Mike Kavis a listé ce qui constitue selon lui les 10 principales causes d'échec des projets d'architectures orientées services. D'après CIO.com, les gens échouent : 1) Parce qu'ils n'arrivent pas à expliquer la valeur métier des SOA Les projets consacrent énormément de temps, de ressources humaines et d'argent à mettre au point la meilleure architecture possible - ce qui est une bonne chose, souligne Mike Kavis. Toutefois, là où le bât blesse, c'est que généralement, cela se fait au détriment de toute discussion avec le métier. Du coup, lorsque l'architecture est prête, personne n'en veut car personne n'en comprend l'intérêt. Il faut donc, dit-il, commencer un projet en gardant en tête le besoin de répondre à des problématiques métier. Le mieux étant de présenter une « killer app », l'application qui résoudra tant de problèmes métier que les fonctionnels en redemanderont. Pour lui, le BPM (Business process management, gestion des processus métier) est sans conteste LA 'killer app' pour les SOA. 2) Parce qu'ils sous-estiment l'impact des changements organisationnels Les SOA impliquent souvent de vastes changements dans l'organisation des entreprises, « surtout si ces dernières n'ont pas d'architecture d'entreprise bien établie », écrit Mike Kavis. Cela génère bien sûr des incertitudes, une peur de l'inconnu, et donc une résistance au changement. A chaque niveau de l'entreprise, chacun a ses inquiétudes, et cela doit être pris en compte, au besoin en embauchant un expert de la gestion du changement. 3) Parce qu'ils n'obtiennent pas de soutien haut placé Il est très improbable qu'une initiative SOA réussisse si elle n'est pas sponsorisée par quelqu'un de haut placé dans la hiérarchie (CEO, CIO, CTO, etc.). De fait, même les SOA peuvent se traduire en une multitude de projets. Il n'existe pas de petit projet SOA. Une initiative SOA concerne par définition plusieurs - sinon tous - départements de l'entreprise, puisqu'il s'agit de casser les silos. Il faut donc pouvoir compter sur le soutien de quelqu'un qui sera capable de contourner ou de briser les obstacles. Le mieux, écrit Mike Kavis, est de confier ce rôle à un dirigeant métier lorsque le bénéfice métier de l'initiative SOA a été clairement défini. [[page]] 4) Parce qu'ils essaient de faire de la SOA à l'économie Les projets SOA coûtent cher, il faut en être conscient. En plus des investissement technologiques dans le middleware, indique Mike Kavis, il faut prévoir les outils de gouvernance, la formation, l'aide de consultants, etc. Certaines entreprises essaient de tout faire elles-mêmes pour limiter les coûts, écrit-il, mais « à moins que vous ne soyez bardés de gens très expérimentés en SOA, se passer d'une aide extérieure afin d'économiser de l'argent vous conduira droit au désastre ». L'éditorialiste donne, avec un certain angélisme, deux conseils dans ce cas : d'une part, présenter un projet qui, s'il est suffisamment bien argumenté, suffira à décider le financement de l'initiative, et d'autre part, recourir éventuellement à des projets Open Source pour diminuer le coût d'implémentation. 5) Parce qu'ils manquent des compétences nécessaires Ce point est un corollaire du précédent - et reflète la culture américaine sur la mobilité dans l'emploi : souvent, par souci d'économie, l'entreprise tente de conduire des projets SOA avec des gens qui manquent d'expérience en la matière. Alors qu'elle a besoin au contraire d'experts, qu'il s'agisse d'architectes, de gens capables d'administrer les outils ou de modéliser les processus métier. Faute de pouvoir embaucher, Mike Kavis recommande de demander beaucoup d'argent dès le départ - pour ne pas donner l'impression ensuite que l'initiative SOA est un puits sans fond - à investir dans la formation des informaticiens et des responsables métier auxquels les outils de BPM sont destinés. 6) Parce qu'ils gèrent mal leur projet Le meilleur projet SOA n'arrivera pas au bout si la gestion du projet est défaillante. Comme pour tout projet, il faut gérer les risques, faire en sorte que chacun adhère au planning, etc. Sauf que cela se fait à une échelle extrêmement grande. D'où le conseil de Mike Kavis : « Mettez votre meilleure ressource en gestion de projet sur ce projet. » Et comme on le lit dans les annonces de recrutement, ce serait un plus si « cette personne était suffisamment technique pour comprendre les SOA au niveau conceptuel ». 7) Parce qu'ils voient la SOA comme un projet plutôt que comme une architecture Mike Kavis dénonce « la naïveté de nombreuses entreprises » qui croient que les SOA sont juste un projet comme un autre. Or, elles impliquent la collaboration de nombreux acteurs, spécialistes des ESB (Enterprise Service Bus), des interfaces utilisateurs, de la modélisation de processus, du réseau, de l'architecture des données, etc. Plutôt que de perdre du temps dans de multiples réunions, l'auteur préconise de rassembler toutes ces personnes sur un plateau 'open space' avec moult tableaux blancs pour favoriser le travail collaboratif. [[page]] 8) Parce qu'ils sous-estiment la complexité des SOA D'un point de vue utilisateur, SOA et BPM sont d'une grande simplicité : ils font apparaître comme des applications intégrées des centaines de logiciels et services applicatifs. Vu de l'intérieur, cela représente en revanche un exercice redoutable, même pour des développeurs aguerris. Il faut donc s'attendre à ce que de nombreux obstacles se dressent sur la route, que cela vienne des produits des éditeurs qui manqueraient de maturité ou bien de l'intégration avec le système d'information existant. Dans tous les cas, prévient Mike Kavis, il faut fixer des objectifs réalistes, ne jamais oublier l'infrastructure de sécurité pour chaque sous-projet, et procéder par itérations afin de délivrer souvent de la valeur au métier. 9) Parce qu'ils ne parviennent pas à mettre en place une gouvernance SOA Qu'on l'appelle management ou gouvernance - le terme qui effraiera le moins les équipes, ou rencontrera la meilleure adhésion - il faut mettre en place une politique de gestion globale. Tant au moment de la conception (pour faire en sorte que les développements respectent les principes architecturaux, notamment) qu'après le déploiement, pour comptabiliser les services consommés, superviser les performances, etc. Mike Kavis recommande d'investir dans une équipe dédiée, avec des outils spécifiques, qui gagnera en maturité en même temps que le reste des équipes et des projets. 10) Parce qu'ils laissent les éditeurs guider l'architecture Mike Kavis met en garde contre ce que Ron Schmelzer qualifie de VDA (Vendor driven architecture, ou architecture guidée par le fournisseur) : « Le but du fournisseur est de vous vendre autant de choses que possible. Votre but est d'implémenter avec succès la SOA, et de procurer à votre entreprise le maximum de bénéfices avec le minimum de dépenses. Voyez-vous le conflit d'intérêts ? » Bien sûr, les fournisseurs arguent que leur acheter leur plateforme complète réduira les coûts d'intégration - ce que l'auteur conteste, puisque ces plateformes sont justement constituées de multiples produits rachetés et agrégés. Il s'agit donc ici d'une étape cruciale, qui consiste à prendre le maximum de renseignements auprès des experts et des pairs, à bien définir son besoin avant de consulter les fournisseurs, et à demander à ces derniers des preuves technologiques de ce qu'ils avancent. Il est bien évidemment tentant de s'en remettre à l'expertise d'un éditeur, mais sachant combien les projets SOA sont coûteux, et prévus pour durer des années, cette décision est l'une des plus difficiles à prendre. Titre de l'encadré: En savoir plus Encadré: - L'opinion de Mike Kavis sur CIO.com (...)
(09/07/2008 16:33:37)Genesis, le projet de mashups collaboratifs d'Adobe
Le projet Genesis d'Abode vise à proposer un espace de travail composé de mashups qui regroupent des sources d'information diverses sur un thème donné. Adobe précise qu'il sera possible de partager des projets Genesis. Dans un premier temps, ce partage se fera au travers d'une infrastructure proposée par l'éditeur. Dans un second temps, une autre version permettra l'hébergement des serveurs au sein même des entreprises utilisatrices. Bâti sur un client gratuit AIR (Adobe Integrated Runtime) d'Adobe, Genesis sera lancé en bêta restreinte d'ici la fin de l'année. Né d'échanges avec Business Objects, Genesis se pose en concurrent d'IBM et de son "mashup center". Adobe mène actuellement une campagne auprès de directions opérationnelles de sociétés américaines pour affiner son projet. L'éditeur prévoit toutefois qu'il facturera le partage d'information via son infrastructure, en particulier le temps réel, sous la forme d'abonnement. Ces projets de partage d'information soulèvent toujours des inquiétudes en termes de sécurité. Adobe précise que la version hébergée proposera aux utilisateurs un outil de gestion des contacts. La seconde version, installée sur site, pourra utiliser les renseignements contenus dans les annuaires LDAP. (...)
(07/07/2008 16:56:19)IBM propose de tester gratuitement son « mashup center »
Un outil d'assemblage de services en ligne, accessible aux utilisateurs métier : telle était la promesse d'IBM lors de la présentation de son Mashup Center, début avril à Las Vegas. Désormais, tout un chacun peut vérifier si la promesse est tenue : l'offre Mashup Center est disponible gratuitement pour les utilisateurs enregistrés sur le portail Lotus Greenhouse. L'outil graphique de création de widgets - services dotés d'une interface utilisateur - Lotus Widget Factory n'est pas encore en ligne, mais l'éditeur assure qu'il fera bientôt partie de l'offre. (...)
(03/07/2008 12:35:09)L'éditeur de l'ESB Open Source Mule s'attaque à la gouvernance SOA
« Nos clients avaient besoin d'un outil pour gérer leurs services, s'assurer que les déploiements soient conformes à certaines règles... » Ross Mason, cofondateur et directeur technique de Mulesource, est à Paris cette semaine, à l'invitation d'Octo Technology, pour son Université du SI, et de son partenaire sur le marché français, la SSII Ippon Technologies. Le créateur de l'ESB Open Source Mule en a profité pour vanter son tout nouveau produit, Galaxy, un annuaire de services présenté comme un outil de gouvernance des SOA (architectures orientées services). Tout comme le bus de services d'entreprise Mule, Galaxy existe en deux versions : une 'Community Edition', Open Source, sortie en janvier dernier, et une 'Enterprise Edition', commercialisée, qui est sortie lundi dernier. Cette édition de Galaxy fournit des services de haute disponibilité, un moteur de recherche de services, la capacité de stocker des documents bureautiques décrivant les services, ou encore la capacité à gérer les changements de version. Cette dernière fonction est particulièrement appréciable lorsque le nombre de services passant par l'ESB augmente. Une entreprise peut ainsi rendre obligatoire le déploiement des services à partir de l'annuaire, afin d'éviter les conflits de versions et garder une trace claire des événements. Pour Ross Mason, il s'agit de la première offre de gouvernance des SOA en Open Source. Plus prosaïquement, il s'agit d'un ajout essentiel à l'ESB, nous a expliqué Ross Mason, « à un prix abordable pour la grande majorité des utilisateurs ». (...)
(30/06/2008 11:50:40)Progress ajoute les outils de tests de Mindreef à son offre Actional
Dans la foulée du rachat d'Iona par Progress, l'éditeur a procédé à une autre acquisition, toujours dans les domaine des services Web et des architectures orientées services (SOA). Progress, ou plus exactement Actional, sa division consacrée aux outils de supervision, a mis la main sur Mindreef, éditeur de la suite d'outils Soapscope. L'offre de Mindreef se situe à mi-chemin des outils de test et des outils de développement ; destinée tant aux architectes qu'aux développeurs ou aux testeurs, elle permet de mettre en place des règles de validation pour les développements et de procéder à des tests dans un cadre de cycles courts. Soapscope sera rattaché à l'offre d'Actional (qui fait partie des produits retenus par Yphise), de la même façon que Xcalia a été rattaché à Datadirect, une autre entité du groupe Progress. L'éditeur reste en effet fidèle à sa stratégie de fournir des outils pointus dans chaque secteur, sans chercher à vendre une plateforme complète, comme nous l'expliquait Giles Nelson, directeur technique de Progress, à l'occasion du rachat d'Iona. (...)
(26/06/2008 17:03:05)Progress complète son portefeuille SOA avec l'offre d'Iona
Qui sera le plus grand des acteurs de taille moyenne dans les architectures orientées services (SOA) ? Progress a conclu un accord pour racheter Iona (pour 4,05 $ par action, soit environ 149 M$), prolongeant ainsi une série d'acquisitions qui en fait un acteur sérieux sur le marché, derrière Tibco et Software AG. Progress a réalisé un chiffre d'affaires de 494 M$ en 2007, et Iona 77,7 M$. L'addition des deux positionne l'éditeur juste derrière Tibco (577,4 M$), lui-même étant devancé par Software AG (621,3 millions d'euros). Toutefois, comme le rappelle Henry Peyret, analyste senior de Forrester Research, « Progress ne réalisait jusqu'à maintenant pas plus de 50 M$ en SOA ». Selon Giles Nelson, directeur de la technologie au sein de Progress le montant des licences SOA atteindrait en fait 17% du chiffre d'affaires, soit environ 84 M$. Et de commenter : « Cela nous aidera à renforcer notre position en tant que fournisseur indépendant de logiciels SOA. » Artix représente un tiers du chiffre d'affaires d'Iona Iona est quant à lui un spécialiste du middleware - même si là aussi la part des SOA est minoritaire. Sa ligne Artix, dédiée aux SOA, est en progression constante (14% du chiffre d'affaires en 2005, 26% en 2006, 33% en 2007), mais l'éditeur irlandais fait encore près des deux tiers (65%) de son chiffre d'affaires avec Orbix, son offre pour architectures Corba. Et comme l'explique Giles Nelson, les deux architectures sont relativement proches, et la technologie d'Iona jette justement un pont entre les deux. En outre, l'éditeur d'Artix dispose grâce à la robustesse de son offre Corba d'une bonne base installée dans les domaines de la finance et des télécoms - qui intéresse fortement Progress. [[page]] « Toutes les lignes de produit devraient être conservées, » poursuit Giles Nelson. Cela paraît évident pour un certain nombre de technologies, comme « l'annuaire de services de la ligne Artix, qui complétera l'offre de gouvernance Actional », alors que jusqu'à présent, Progress s'appuyait sur un partenariat avec Systinet (entité appartenant désormais à HP). En revanche, la partie ESB, bus de services d'entreprise, risque de créer de la confusion dans l'esprit des clients, prévient Henry Peyret. Dès la finalisation de la transaction, Progress se retrouvera en effet à la tête de trois offres, la sienne, Sonic ESB, Artix ESB d'Iona, et le projet Open Source de l'éditeur irlandais, Fuse. Progress a trois ESB à départager et à positionner sur le marché « Sonic est plus orienté réseau, répond Giles Nelson, lorsque vous cherchez une infrastructure de messagerie interapplicative robuste, en environnement hautement distribué. Artix est plus orienté RPC [appel de procédure distant, NDLR] entre points de terminaison hétérogènes : applications C++, objets Corba, .Net... » Fuse est considéré de son côté comme un moyen de démarrer avec ce type de technologie. Dans tous les cas, cette multiplicité de produits ne gêne pas Progress le moins du monde. L'éditeur reste campé sur sa stratégie consistant à proposer du « best of breed », des briques capables de prendre place dans n'importe quelle architecture, afin de résoudre un problème technologique ponctuel. « Iona avait la même stratégie, continue Giles Nelson, de fournir des produits capables de fonctionner de façon autonome aussi bien qu'ensemble. C'est un élément différentiateur clair entre nous et le gros des éditeurs. » [[page]] Cette stratégie n'avait toutefois guère souri à Iona, dont le chiffre d'affaires stagnait, et dépendait très fortement de quelques gros clients. Boeing comptait ainsi pour 18% de son chiffre d'affaires, et AT&T pour 11%. L'éditeur se savait fragile, et avait mandaté la banque Lehman Brothers en février dernier pour trouver un acquéreur. « Alors que Software AG a très bien su se positionner sur le marché des entreprises de taille moyenne, Iona a manqué ce positionnement. Du moins en termes marketing, car dans les faits, ils y étaient. » Pour l'analyste de Forrester, un gros travail d'explication attend Progress : « Ils ont besoin d'un positionnement stratégique, d'indiquer quels clients ils visent, quelles solutions ils apportent. Je crois que la stratégie du 'best of breed' n'est plus suffisante aujourd'hui. Cela marchera pendant peut-être encore un an ou deux, mais cela devient de plus en plus complexe pour les clients, qui attendent des éditeurs qu'ils fassent le travail d'intégration. Pour moi, il est temps d'établir un vrai message de plateforme. » (...)
| < Les 10 documents précédents | Les 10 documents suivants > |