Archives pour la catégorie Architecture

Information Architecture

Le concept d’EIA (Enterprise Information Architecture, à ne pas confondre avec EAI = Enterprise Application Integration) est un concept marketing qui désigne un ensemble d’activités informatiques prenant une importante croissante dans l’entreprise : la mise en place de référentiels de données communs à l’ensemble des fonctions, entités, divisions et systèmes d’une même entreprise. Ce concept s’applique dans le cadre de projets liés aux technologies de méta-annuaires (pour constituer et faire vivre des référentiels d’identités de personnes et/ou de structures), aux technologies d’EAI (pour intégrer des systèmes applicatifs transactionnels les uns aux autres, tels qu’un système de prise de commande et un système de pilotage de la production ou de gestion des stocks), et aux technologies de datawarehouse (pour regrouper en un même lieu et sous une forme cohérente les données produites par tous les systèmes informatiques de l’entreprise de manière à produire des tableaux de bord par exemple).
Avec l’émergence des technologies du Web Sémantique, ce concept d’EIA se décline en SIA, comme Semantic Information Architecture. Cet article explique en quoi une activité de SIA permet, par une meilleure compréhension des données de l’entreprise, de créer de la valeur pour celle-ci.

Stratégie annuaires

Pour mener à bien un projet annuaire d’entreprise (avec ou sans méta-annuaires), Phil Windley recommande de se doter d’une démarche stratégique en 5 étapes :

  1. Créer une « Architecture de l’Information dans l’Entreprise » (EIA = Enterprise Information Architecture) pour expliciter le contexte métier de votre stratégie annuaire
  2. Déterminer les standards que votre organisation choisit de respecter
  3. Inventer une politique d’authentification et d’autorisation cohérente avec votre EIA
  4. Planifier et implémenter les services d’annuaires nécessaire à la mise en place de vos politiques
  5. Publier une politique de protection des données privées qui soit en accord avec votre cadre législatif et les attentes de vos parties prenantes

Windley identifie plusieurs sources de gains pour les projets de gestion d’identité : une approche cohérente et systématique des clients, une sécurité accrue pour les applications et l’information « corporate », une réduction des coûts d’administration des utilisateurs et des droits informatiques, et une meilleure application des politiques de sécurité internes et externes. Pour finir, il conclut par :

Construire une stratégie d’identité électronique qui fonctionne requiert un effort considérable, mais si vous négligez de faire cet effort, plutôt que de constituer un actif, la gestion des identités deviendra une source constante de problèmes et un obstacle pour vos initiatives stratégiques »

rdflib and ROPE

I just blog this Bob DuCharme article so that I can remember where practical information about rdflib can be read.
By the way, I have tested the very pre-pre-release of Reinout’s ROPE (see ROPE = Rdflib + zOPE). And I could install it on a Zope 2.7.0b3 fresh install. It was quite easy to install it. But, as Reinout said, it is still a very early release and, as you can see on the attached screenshot, there is much work to be done before it is really usable. This screenshot is just a hint for Reinout : if you add several namespaces into a rdfstore (shouldn’t you name it a « rope » ?), they end up displayed one next to another instead of being options of the same HTML select widget. Anyway, I am looking forward further releases of Rope.

Produit pour la gestion sémantique de contenu

La société Voquette offre une technologie nommée SCORE, qui prétend faciliter la gestion sémantique de contenu. Cette publication auprès de l’IEEE présente leur vision du web sémantique.
Les activités commerciales que Voquette identifie dans le domaine du Web Sémantique portent sur le développement de taxonomie ou d’ontologies ainsi que de standards de méta-données pour l’entreprise, l’organisation de contenus selon ces taxonomies, l’annotation de contenu avec ces méta-données, l’analyse de contenu à la recherche de « motifs » (patterns), le « data mining » pour identifier les relations implicites entre des données provenant de sources différentes. Les principales applications actuelles du Web Sémantique concernent la recherche et la personnalisation, l’organisation du contenu et des portails d’entreprise, la syndication de contenus. Les technologies du Web Sémantique trouvent leurs débouchés dans les marchés de la gestion de contenu et de la gestion des connaissances (knowledge management). Voquette définit plusieurs concepts relatifs à l’usage de ces technologies.
La recherche sémantique et la personnalisation sémantique consistent, pour un produit logiciel, à différencier un mot selon ce qu’il désigne. Par exemple, le mot « palm » tel qu’employé par l’utilisateur désigne-t-il un produit matériel (« Palm Pilot »), un produit logiciel (« Palm OS »), une société (« Palm ») ou encore un élément d’anatomie humaine (la paume de la main) ? Un moteur de recherche sémantique saura distinguer ces concepts et aider ainsi son utilisateur à préciser ses requêtes ou bien à ne considérer que les résultats pertinents sur le plan conceptuel.
La gestion des méta-données sémantique permet d’organiser un contenu, par exemple documentaire, non seulement en fonction de méta-données syntaxiques (longueur d’un document, date de création, format du fichier) mais aussi en fonction des concepts auxquels ce document est lié (le groupe d’auteurs qui l’ont écrit, sa thématique principale, la raison pour laquelle il a été écrit, …)
La normalisation sémantique consiste à établir des relations d’équivalence entre différentes formes syntaxiques désignant une même entité comme par exemple, pour désigner le PDG d’une société, le nom de celui-ci, son surnom, sa fonction (« PDG de telle société »), etc. La normalisation sémantique implique généralement le choix d’une forme canonique pour identifier le concept désigné (une norme consistant par exemple à prendre le prénom plus le nom de famille d’un individu).
L’association sémantique consiste à établir des recommandations (recommander un contenu pour une personne donnée), des évaluations de pertinence (établir la force du lien sémantique entre un contenu et une requête) ou, d’une manière plus générale, estimer la probabilité qu’une entité donnée soit liée à une deuxième entité par une association logique donnée.
L’architecture du système SCORE est composée d’agents extracteurs de contenus, paramétrés à l’aide d’une « boîte à outils d’extraction ». Ces agents permettent à la fois d’alimenter et de faire évoluer un modèle de référence et d’alimenter un corpus de contenus faisant référence à ce modèle par le biais de relations sémantiques (annotations sémantiques). Ces relations sémantiques sont enrichies automatiquement par le biais d’un composant capable de procéder à ces catégorisations automatiques. Ensuite, un « moteur sémantique » permet de puiser dans le modèle et dans le corpus les contenus pertinents. SCORE fournit une application de « tableau de bord sémantique » qui s’appuie sur ce moteur ainsi qu’une API qui permet au développeur de construire ses propres applications sémantiques de gestion de contenu. Les caractéristiques principales qu’ont recherché les concepteurs de SCORE sont sa performance et sa capacité de montée en charge plutôt que la sophistication de ses mécanismes d’inférence. Le moteur permet donc uniquement de parcourir les relations sémantiques établies et n’offre pas de capacité d’inférence similaires à celles d’un moteur de raisonnement logique (systèmes experts, …). Enfin, il convient de noter que le composant de catégorisation automatique s’appuie sur une combinaison de plusieurs méthodes de catégorisation : probabilistique (bayésienne), par apprentissage (modèles markoviens) et par approche formelle.

La panoplie du parfait petit Zopeur

Voici les ressources nécessaires à tout développeur francophone qui veut se plonger dans la technologie Zope avec la meilleure efficacité :

Agrégation de carnets Web dans l’entreprise

Les agrégateurs de contenu pour carnets Web permettent aux entreprises d’unifier la publication d’informations issues de leurs multiples systèmes informatiques, quand bien même ceux-ci s’appuient sur des technologies propriétaires et hermétiques. Il s’agit d’une forme de communication partiellement concurrente des systèmes dits de « portail ».
Ainsi, une entreprise américaine a constaté que la principale source d’information quotidienne de ses employés était la messagerie électronique. Pourtant, la messagerie n’offrait pas un mode de communication des plus efficaces pour accéder à l’information critique pour les activités quotidiennes. Les utilisateurs se plaignaient de la difficulté qu’ils avaient à accéder à l’information pertinente. Les listes de diffusion de messagerie étaient difficiles à gérer et à maintenir au rythme des mouvements de personnel. Quant aux portails intranet, ils ne pouvaient saisir l’information critique quotidienne qu’au prix de licences logicielles très coûteuses.
C’est pourquoi cette société a adopté l’usage des carnets Web et des agrégateurs de contenu qui leur sont associés. Sur ces carnets, chaque employé des équipes de développement produit a été invité à publier des foires aux questions, ses rapports d’avancement de projets, les résultats de son travail quotidien et ses documents de conception. Les forces de vente ont été invitées à inscrire dans leurs carnets Web l’avancement de leurs travaux de prospection commerciale. De plus, certains des systèmes informatiques existants, qu’il s’agisse d’applications métiers ou de logiciels de portails ou de gestion de contenu, ont été équipés d’une interface permettant de publier automatiquement certaines de leurs données sous la même forme que celles des carnets Web.
Chaque utilisateur a ensuite été équipé d’un logiciel d’agrégation de contenu, qui va chercher les dernières informations les plus pertinentes sur chacun des carnets Web des collègues et des systèmes automatisés ; ces informations s’affichent regroupées par catégories. Grâce au logiciel d’agrégation, chaque utilisateur peut consulter d’un rapide coup d’oeil l’information concernant l’activité de ses collaborateurs directs, la trier, l’archiver, la parcourir par mot-clef et, éventuellement, la commenter ou l’enrichir à leur tour sur leur propre carnet. Contrairement au système de messagerie, ce n’est pas au producteur de cette information de décider à quels « consommateurs » il la destine. C’est à chacun d’orienter son agrégateur personnel de contenu vers les sources d’information pertinentes pour son activité.
Cette forme de communication, contrairement aux logiciels de portails intégrés tels que Sharepoint Portal, repose sur une technologie standardisée (XML + RDF + RSS) qui est soutenue par une communauté de développeurs informatiques à la fois étendue, diverse et ouverte. Le caractère ouvert de cette technologie a permis à la société utilisatrice de choisir, pour en bénéficier, un logiciel open source qui l’implémente de manière satisfaisante et surtout gratuite. L’économie des licences logicielles a été significative par rapport à la généralisation d’un logiciel de portail.

Carnets Web pour la veille concurrentielle

L’usage croissant des « carnets Web » (ou weblogs ou blogs) trouve des débouchés originaux dans le domaine de la veille concurrentielle (voir la présentation Powerpoint liée). La tenue de carnets Web individuels par une large population de veilleurs, marketeurs, chercheurs et commerciaux dans une entreprise permettrait de rendre tangible et exploitables les « signaux faibles » qui sont les pépites de la veille, avec un investissement technologique tout à fait minime.

Plone va au COMDEX

Le produit de gestion de contenu Plone a été désigné par « la communauté open source » comme étant le logiciel libre méritant le plus d’être présenté au salon informatique américain COMDEX (Las Vegas). L’éditeur O’Reilly lui offre donc un stand. Suite à cet événement, les lecteurs de Slashdot évoquent les attraits principaux de Plone, ainsi que de Zope, le serveur d’application Python sous-jacent. De tous les serveurs d’application du marché, Zope aurait la capacité de montée en charge « la plus transparente » : la technologie de clustering ZEO n’imposerait pratiquement aucune modification du code des applications. Zope fournirait une technologie de gestion de cache mature et une interoperabilité indubitable. Zope est comparé au noyau linux et Apache et représenterait un avenir important pour le logiciel libre en lui permettant notamment d’entrer dans l’univers applicatif (« move open source software ‘up the stack’ to higher levels »). L’interface utilisateur de Plone (en particulier dans sa version 2.0) serait exemplaire en termes de modularité et de respect des standards d’accessibilité. Elle incarnerait l’état de l’art en matière d’architecture Web et d’extensibilité.
Enfin, les commentateurs soulignent l’importance et la diversité de la communauté d’utilisateurs et de développeurs de Plone, qui dépasserait celle de toute autre logiciel libre de gestion de contenu. Selon l’un des lecteurs, l’un des meilleurs atouts de Zope et de Plone serait cette communauté et son enthousiasme ; cet enthousiasme serait un indicateur de la disponibilité du support technique autour de ce produit.
Le nombre de société de services informatique offrant du support sur les technologies Zope et Plone semble confirmer cet indicateur.

Catégorisation automatique par réseaux bayesiens

Jon Udell a expérimenté l’utilisation de réseaux bayesiens pour la catégorisation automatique de contenus. Ces expérimentations, bien que séduisantes et prometteuses, ne se sont pas révélées concluantes. Les réseaux bayesiens sont efficaces pour classer de manière binaire (spam ou non spam ?) des contenus lorsqu’ils sont entraînés sur des échantillons de plusieurs centaines d’éléments. Par contre, lorsqu’il s’agit de multiplier les classements possibles (n rubriques) et, a fortiori, de réduire l’échantillon d’apprentissage (quelques dizaines d’entrées dans un carnet Web), ils deviennent relativement peu pertinents : entre 20 et 40% d’efficacité seulement dans les tests de Jon Udell.

Alternatives open source à MS Access

Il semblerait qu’il apparaisse enfin des alternatives open source à MS Access : Rekall (distribué sous licence GPL ici et lu et discuté sur Slashdot) mais aussi un module d’OpenOffice (il doit être bien caché car la dernière fois que j’ai rapidement testé OpenOffice, je ne l’ai pas trouvé). Tiens, tiens, amusant, le langage de script de Rekall est Python !
Pour mémoire, toujours en Python, les produits zetadb et Formulator, dans l’environnement Zope, pourraient bien servir à faire la même chose mais en version Web.

EJB : ce qu’il ne faut pas faire avec

A l’occasion de la sortie du livre « Bitter EJB », Slashdot fait le point sur ce qu’il ne faut pas faire avec les EJB. Il est rappelé que « bien qu’outils incroyablement puissants entre les mains d’architectes expérimentés, les EJBs sont le sujet d’un grand nombre de mauvais emploi par les développeurs novices qui en font un usage inapproprié ». C’est souvent la complexité des EJB qui tourne les entreprises vers d’autres plate-formes applicatives. Encore une fois, il est rappelé qu’un fusil à éléphant n’est pas forcément l’armement adéquat pour se débarrasser d’une souris domestique.
Mais les remarques les plus intéressantes viennent, comme souvent, des lecteurs/commentateurs de Slashdot. Ceux-ci, dans leur majorité, sont perplexes devant les EJBs. Ainsi, l’un d’entre eux affirme : « La grande majorité des gens avec qui j’ai parlé semble montrer qu’ils n’ont jamais rencontré de projet de développement pour lesquels l’utilisation d’EJB n’aurait pas été totalement superflue et pour lesquels des solutions plus simples, plus faciles à maintenir et moins coûteuses n’a pas été finalement retenue. » Encore un développeur amer au sujet des EJB : « [Avec les EJBs,] il vous faut construire 10 systèmes qui ne marchent pas avant de pouvoir deviner comment en faire un qui fonctionne. Franchement, les EJBs ne m’ont pas l’air de valoir la peine qu’il faut pour les apprendre. » Un peu plus loin : « Si il y a bien une technologie qui est en risque d’extinction dans le monde Java, c’est bien les EJBs. Pratiquement tous les nouveaux projets J2EE dont j’entend parler se tiennent bien à l’écart des EJBs et adoptent des solutions plus simples du type servlet/JSP avec JDO pour la persistence. Ensuite vous distribuez le système horizontalement avec mod_jk ou un équilibreur de charge matériel… Vue leur complexité et la nature restrictive de leur API, je n’ai vraiment pas besoin de cette technologie. » Un autre s’interroge : « Les EJBs… semblent causer plus de problèmes qu’elles n’en résolvent… Pour quel type d’usage sont-elles réellement appropriées ? Je n’ai pas été capable de le deviner la dernière fois que j’ai travaillé en environnement J2EE. ».
Heureusement, au moins un développeur Java cite un cas d’utilisation appropriée pour cette technologie : « Je suis un architecte qui travaille sur une application d’entreprise de plusieurs millions de dollars et notre expérience avec les EJB a été jusqu’ici extrêmement positive. Nous nous sommes bien gardés d’adopter les ‘entity beans’ en nous contentant d’une couche JDO… Avec du matériel modeste, nous remplaçons de manière assez rentable l’application mainframe que nous réécrivons ainsi. » Et un autre de conclure : « Si vous n’avez pas besoin d’une isolation transactionnelle dans le cadre d’un système distribué, les EJBs sont superflues. »

Comment le Web Sémantique se construit

Burningbird expose sa vision des dynamiques de construction du Web Sémantique : un mouvement bottom-up et progressif plutôt qu’un deus ex machina avec éclairs, tonnerre et fanfare, un mouvement par lequel on verra apparaître non pas le Web Sémantique mais un web sémantique. Son idée est que le bidouilleur qui veut publier des données sur le Web sous une forme digestible pour d’autres systèmes informatiques adoptera peu à peu le modèle de données RDF pour des motifs économiques.
En effet, grâce à ce modèle, le jour où il voudra réutiliser ses données pour les intégrer avec celles du voisin et construire une nouvelle application, « il n’aura plus qu’à » ajouter des règles logiques par-dessus. Celles-ci s’appliqueront sans douleur car le modèle RDF est conçu pour l’application de règles de ce type et préserve, pour ce faire, l’identité des sources de données. Ainsi, ces règles logiques pourront simplement dire des choses du genre : « Selon la source C, la ressource XYZ au sens que lui confère la source A est équivalente à la ressource 123 au sens que lui confère la source B ». Chaque source (chaque « auteur » de données) peut donc faire coexister ses données avec celles de ses voisins, qu’elles soient ou non cohérentes avec celles-ci. Les systèmes à base de règles sont là pour recoller les morceaux a posteriori et sans douleur. Cela suppose simplement que le bidouilleur ait adopté le bon modèle de donnée a priori.
Par contre, si le concepteur n’a pas anticipé ce besoin de réutilisation de données et s’est par exemple contenté d’adopter un vocabulaire XML spécifique, il devra souffrir à chaque fois qu’il voudra les intégrer avec celle du voisin car il devra alors développer et redévelopper des moulinettes spécifiques de transformation de ses données (XSLT, …). Investir dans l’adoption d’un modèle « universel » de données tel que RDF se révèlerait donc rentable dès que les réutilisations de données se multiplient.