Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

The Mit's Blog

En plus d'intégrer et skier, il sait même écrire !
(Blog de Renaud Comte)

Actualités


  • Ancien MVP SharePoint 8 ans ...
    Des projets .Net, SharePoint 2013 ou Office 365 ??

    Contactez-nous :

Archives

[AVIS] De la différence philosophique entre Lotus Notes et SharePoint 2007.

Voici un billet d'un nouveau genre, entre le retour d'expérience et le recul critique, en résumé, Mon avis personnel sur une problématique technologique.


Avis que je vais tenter de défendre, argumenter et commenter. A vous ensuite de vous faire votre propre avis sur la question

Bonne lecture (et j'attends avec impatience vos commentaires constructifs, passionnés et passionnants)  

Pour le premier de la série, j'ai choisie un sujet qui revient souvent ces temps ci.

Et par tous les moyens de communication possibles !!!

Par

  • mail
  • courrier
  • mobile
  • Skype
  • MSN
  • ET même mon voisin de compartiment dans le TGV !!!!

Nous dirons donc un sujet bien "à la mode" : Migration de bases Lotus Notes vers SharePoint 2007

Attention, il ne s'agit que de mon avis personnel et n'engage que moi et pas mon employeur ou tout éditeur partenaire.

Il est vrai que bien des sociétés ont déployés moult serveurs et sites SharePoint, et souvent avec réussite.

Le tout soutenu par des user-cases accréditant encore plus un marketing assez efficace de Microsoft sans pour autant être vraiment agressif (du moins sur ce sujet là).

Un succès qui se confirme doucement mais sûrement et qui commencent même à convaincre bien des entreprises de franchir le pas.

Et pas n'importe lequel : Migrer un environnement Lotus Notes à la technologie SharePoint...

Il y a 6 ans, j'assurais déjà des projets où on évoquait la possibilité de remplacer bien des systèmes de gestion électronique de connaissance/knowledge sharing via une technologie naissante comme SharePoint 2001.

Avec le temps, évolution oblige, SPS 2003 s'est mis en concurrence naturelle avec Lotus Notes.

Clairement, la matrice avantage / inconvénient entre SPS 200X et Notes 4/5/6 n'était pas à l'avantage de SharePoint.

Mais voila, les années passent, Microsoft apprend, les technologies évoluent et SharePoint 2007 arrive.

Certains remarqueraient même que des hommes-clé ont changé de clan

Genre, Ray McOzie

Créateur de Lotus Notes qui quittera IBM pour créer Groove et qui se retrouve finalement Chief Technical Architect de ... Microsoft.

Je n'ose même pas me projeter sur les prochaines versions de SharePoint mais restons contemporains et revenons sur notre version actuel qu'est SharePoint 2007.

Maintenant, le rapport de force a tendance à s'inverser en la faveur de la SP plate-forme (SP = SharePoint).

Attention, je ne dis pas que Lotus Notes est fini, loin de la, mais voici la tendance actuelle : les demandes de migration sont nombreuses et correspondent rarement à du "Proof Of Concept" !!!

Cependant, ne vivant pas dans un monde merveilleux où tout est interopérable en 2 clicks, où tout le monde se met autour d'une table et arrive à se décider sur une norme, où il ne pleut jamais quand on tond la pelouse,... je dois me raccrocher au vrai monde.

Celui de la vraie vie avec de vrais gens, avec des serveurs, des technologies propriétaires et surtout de nombreuses spécificités.

Dans le petit monde du KM, mes (nos) chers amis consultants fonctionnels parleront toujours de :

  • Bases de connaissances
  • Expérience utilisateurs
  • Catégorisation et taxonomie de l'information
  • Référentiel d'entreprise
  • Espace de collaboration et de publication
  • Workflow d'entreprise
  • Dashboard et Scorecards
  • ...

 

Tout un ensemble de sous-ensemble de la poupée russe qu'est l'Enterprise Content Management.

Toute une famille de concepts fonctionnant à merveille sous Lotus Notes et/ou SharePoint 2007.

Si les concepts les rapprochent, une migration d'un outil à un autre ne devrait pas être si problématique, non ?

C'est le principe, en théorie, mais qui n'est pas si évident en pratique.

Je m'explique : pour avoir côtoyé bien longtemps le monde Lotus et avoir vécu l'évolution de SharePoint 2007, j'ai pu remarquer quelques points fondamentalement différents entre ces 2 technologies. Points qu'il vaut mieux savoir pour arriver à migrer d'une technologie à une autre.

Fonctionnellement, il est tout à fait légitime d'envisager et de concevoir de migrer ses bases Notes.

Cependant, exiger une approche iso fonctionnelle, garder l'expérience et les réflexes utilisateurs sont un peu illusoire voire utopique.

En effet, les concepts à la base de l'ECM sont fonctionnels et reposent souvent sur des normes ou des méthodologies de gestion de l'information.

Leur implémentation concrète dépend cependant de l'architecture et de la conception de l'outil, je parlerai même de la philosophie propre de la technologie sous jacente.

Sous entendu, pour nos amis développeurs, il ne s'agit pas forcement de Framework mais de couche produit : chaque produit forme une couche abstraite de son système d'information. Il faut savoir l'exploiter judicieusement et non pas chercher à redévelopper chaque partie.
>>> Il faut plus favoriser l'approche native du produit et l'étendre au besoin des utilisateurs. Chercher à faire forcement correspondre un produit comme Notes ou SharePoint à un fonctionnement spécifique est très risqué. Dans le dernier cas, il faut plutôt s'orienter vers une approche "application spécifique" que chercher à "tordre" l'application pour en faire quelque chose d'autre.

Essayer donc de transformer un serveur SharePoint en une forme d'Exchange pro documentaire ... Il faut mieux préférer :

  • un couple SharePoint / Exchange
  • une application tout .Net
  • autre chose de plus valable

Cependant, Le risque d'effet "usine à gaz", si facile à maintenir dans le temps et à faire évoluer, est bien réel ... Et je ne parle même pas de la capacité des gens à adhérer et à s'approprier de telles applications ...

Donc, il faut toujours respecter la logique propre d'un outil, sa philosophie pour mieux en profiter.

C'est la que se trouve le "hic". Lotus et SharePoint 2007 ont 2 philosophies, 2 conceptions totalement opposés !

Mais qui ne leur interdit en rien de pouvoir offrir au final, en partie, la même offre fonctionnelle autour du Knowledge Management par exemple.

Dés lors, comment arriver à migrer aisément ?

Bien sur, des bases Notes simples avec des workflows basiques se migrent rapidement via les outils/scripts de Microsoft :

Mais dans notre joli monde, il existe très très peu de modèles simples.

Des générations entières de développeurs, de concepteurs et de CP ont rajoutés modifications, composants, workflows et autres customisations pour arriver à répondre à des expressions du besoin de plus en plus exigeantes.

Et plus ces populations utilisaient un outil en particulier, plus ils savaient l'appréhender et profiter de ces forces et éviter ces faiblesses.

Lotus foisonne de Best Practices et de routine interne, comme tout produit, et associé à de bons scénarii fonctionnels, La réalisation d'applications de première qualité n'est pas si compliqué, bien au contraire.

Hors voila, si il est envisageable de conserver ces scenarii fonctionnels comment, mais comment peut on arriver à migrer les Best Practices et autre modèles de conception d'une technologie quand les philosophies sont fondamentalement différentes ?

De mon point de vue, il n'y a pas de miracle, il faut forcement passer par une phase de "concession".

Pour migrer d'une technologie A vers une autre B (genre Lotus vers MOSS), il faut

  1. Définir les 3-4 fonctionnalités majeures ainsi que les 3-4 mineures de A
  2. Recenser les outils et solutions de B cadrant avec les fonctionnalités retenues de A
  3. Proposer des scénarii de modèles équivalents de B par rapport à A
  4. Transiger, négocier sur les fonctionnalités techniquement viables sous B existant sous A
  5. Mettre en avant au mieux la technologie B pour compenser et justifier la migration
    >>> garder bien à l'esprit la loi de Paretto, 20/80 : tout ne sera pas migrable ....
  6. Mettre en place le kit de migration sur des bases dits de référence sur les scénarii définies
  7. Planifier le développement des composants manquants
  8. Planifier la bascule finale
  9. Préparer les formations utilisateurs et la communication sur le nouvel outil B
  10. Exploitez et maintenir la nouvelle technologie (bien souvent on oublie que la maintenance EST différente)

Rien de bien compliqué non ? Tout est question de négociation car effectivement, il ne me semble pas vraiment possible de migrer iso-fonctionnellement les 2 plateformes.

Des documents restent des documents, et la notion d'espace collaboratif n'a rien de révolutionnaire mais dans le détail, l'ergonomie, le rendu, les méthodes de gestion et les outils propres à chaque produit sont souvent largement différent.

Je sais, je semble un peu catégorique mais je vais rajouter quelques arguments plus "techniques" à propos de cette fameuse différence de philosophie, qui complexifie tant le processus de migration.

Vous pourrez ainsi mieux vous faire un point de vue (je suis évidemment preneur de tout feedback, n'hésitez pas !)

Soit dans le désordre :

  • La différence de technologie :
    • SharePoint fonctionne sous environnement Microsoft.
    • Notes aussi mais bien souvent sous environnement AS 400, Unix ou autre
  • La différence d'annuaire
    • SharePoint est PRO LDAP (plutôt AD mais rien de figé grâce aux différents provider)
    • Lotus Notes est PRO NAB : son propre annuaire interne
  • La différence d'origine
    • SharePoint a été pensé en respectant la notion de partage réseau, de hiérarchie du monde Office
    • Lotus Notes a été fondé sur la notion de messagerie, de workflow et stockage
      >>> C'est pourquoi une migration Notes inclue souvent le passage à Exchange ...
  • La différence des fonctionnalités de base
    • Je rappelle que Notes est une technologie déjà bien mature avec des processus et un fonctionnement bien reconnue, SharePoint est plus un outsider, mais quelle outsider !
    • La notion de workflow et de mailing est une des bases de Lotus alors que MOSS découvre doucement cette notion. Moralité, il est plus complexe de rentrer dans la notion de workflow que sous Notes. Actuellement, la création de WF, en dehors de SP Designer ou d'outil tiers reste bien plus compliquée sous SP que son homologue
    • SharePoint reposant sur SQL Serveur, il possède une gestion de la volumétrie largement supérieure à Notes, celui ci restant cependant multi plate forme
    • Exemple de fonctionnalité Notes only:
      • Chaque élément, information se gère un peu comme un mail avec la possibilité de lu/non lui. Assez complexe à réaliser sous MOSS non ?
      • Chaque champ de catégorisation peut gérer sa propre visibilité. Peut être disponible sous MOSS V-Next
      • Notes prône la notion de réplication et de synchronisation, SharePoint, lui, prône la notion d'online. Groove quand à lui change vraiment le mode de gestion mais l'approche global vaut vraiment l'analyse et le détour.
      • Un référentiel global des metadatas : un bon début avec les contents types mais pas forcement suffisant dans tous les scénarii surtout distribué
      • Multilinguisme : ... disons qu'il existe des solutions tierces comme IceFire et AlphaMosaik
      • ...
    • Exemple de fonctionnalités MOSS 2007 Only
      • Intégration du push/pull d'information entre les clients Office et les serveurs Office. Que dire aussi du bandeau customisable ?
      • Intégration fine avec la gamme Microsoft comme Reporting Services, Performance Point, Team System, ...
      • Sa pluridisciplinarité : MOSS est une plate forme pouvant gérer des problématiques du site institutionnel au site social en passant par l'application BI ou le moteur de recherche
      • Evolutivité à court et moyen terme : OBA !
      • ....
  • LA philosophie de base !!!
    • Sous SharePoint, la catégorisation, la sécurité, tout est centré autour de l'information elle même. Sous entendu, le document est maître. Les utilisateurs travaillent sur un document par exemple, et SharePoint vient l'enrichir de tout un environnement de sécurité, metadata et autre.
       
    • Sous Lotus Notes, c'est la notion de Fiche qui est maître. Chaque information est décrite dans une fiche de référence auquel se rajoute toutes les informations de catégorisation possibles. Une fois cette fiche finalisée, un utilisateur peut y accrocher plusieurs documents.

Le dernier point est fondamental !!!

En effet, si avec du temps et un peu de compétence (voir plus), la plupart des problématiques de Workflow peut être re codées (non migrées car l'original ne servira que de base d'écriture des spécifications), il est en autrement pour les applications documentaires.

Le stockage documentaire entre Notes et SharePoint sont opposés, tout simplement.

>>> Attention, je ne dis pas qu'il n'est pas possible de migrer d'une technologie à une autre MAIS qu'il sera TRES difficile d'arriver à un résultat identique ou cohérent.

Cohérent dans le sens ou les utilisateurs retrouveront un maximum de leurs habitudes sous SharePoint s'il faut privilégier le modèle Notes.

Actuellement, j'ai pu rencontrer quelques pistes pour se rapprocher de la philosophie Notes mais aucune n'a su vraiment me séduire

Des lors, quelle est la conclusion possible ?

Rien n'est vraiment évident comme dans tout projet de migration, et rien n'est gagné d'avance.

Bien sur, tout un ensemble d'outil comme le Lotus Transporter Suite ou d'autre éditeurs comme Cashal facilite la vie, il ne simplifie pas tant que ça le problème.

Le seul et vrai problème reste de bien comprendre les points suivants.

Attention, il ne s'agit que de mon avis personnel et n'engage que moi et pas mon employeur ou tout éditeur partenaire.

Soit

  • Une migration est purement technologique et non fonctionnel.
    • Ce ne sont pas des écrans que l'on migre mais des outils et/ou des méthodologies
  • En pratique, il s'agit surtout de transférer les contenus existants dans le nouveau modèle et les réinitialiser
  • Surtout analyser et préparer le terrain de la migration en
    • recensant les fonctionnalités majeures
    • ignorer les fonctionnalités mineures ou les pondérer
    • préparer la phase de formation/transfert de compétence
    • envisager l'impact du la nouvelle technologie sur la culture d'entreprise existante (pour pas mal de société, un mail est dit un notes !)
  • Éviter tous phénomènes de passion et de conservatisme technologiques
    • si une migration est programmée, il y a des raisons, pourquoi lutter contre ?
  • Privilégier toujours
    • la vérité
    • la négociation entre ergonomie et fonctionnalités
    • des workshops basés sur des exemples concrets que de jolis PowerPoint
    • le retour des utilisateurs, ils ont souvent un avis bien plus éclairé de leur outil que l'on croit !

Limite, je conclurais avec 2 ironies simples (et un peu d'humour):

  • Si la migration est simple, c'est qu'il y a forcement un piège.
  • Si l'application d'origine est si exceptionnelle, pourquoi voulez vous tant migrer ?
    (et donc quels sont les vrais arguments et leurs poids dans le projet)

Mais gardez espoir, j'ai rarement vu une migration ne pas aboutir, ce surtout plus un problème d'organisation que de simple technique, non ?

A bientôt et au plaisir de lire vos commentaires,

Renaud Comte aka TheMit (inspiration quand tu nous tiens)
Member of WygTeam
http://www.wygwam.com

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: vendredi 4 avril 2008 16:02 par themit

Commentaires

Gat a dit :

Très bon post qui pourrait être généralisé à la migration en général.

Déjà rien que le passage de SPS 2003 à MOSS 2007 induit des changements et des réflexions à mener (surtout quand il y a eu pas mal de développements).

Bref, ne pas vouloir migrer tel quel sans se poser de question et plutôt réflechir au gain de cette migration, de ce qu'il est important de garder, mais c'est aussi simplement l'occasion de repenser certaines choses (après plusieurs années d'exploitation, on sait généralement ce qui cloche, ce qui aurait pu être mieux réalisé, ce qui ne servait en fait pas, ce qui manque etc...)

(c'est un long post mais c'est je pense que le message est passé :))

# avril 5, 2008 21:43

ROMELARD Fabrice a dit :

Beaucoup de vécu dans ce message :)

J'ai reconnu pas mal de nos anciennes problématiques.

J'ajouterai tout de même pour le cas de Notes que les utilisateurs rabacherons sans arrêt (après la migration) tout ce qui était "facile" avec Notes et complexe avec SharePoint (surtout suivant la version choisie) mais oublierons toujours tous les nouveaux avantages de la nouvelle plateforme ou les galères à outrance de l'ancienne.

Bref, il ne seront jamais content :)

Seconde chose que tous les utilisateurs oublient (ou ne savent pas) :

- NOTES = Client/Server, donc client lourd et tous les développeurs savent bien qu'on peut faire ce qu'on veut en terme de design en C/S

- SharePoint = Web, donc limitation en terme de design, en terme de développement (les glisser/déposer), en terme de rapidité (on est tenu a un Browser la ou le C/S aura son fichier de chache local, ...), ...

Une autre part entre Notes et SharePoint :

- Les formulaires -> Notes permet de faire des forms très rapidement et très avancé, la ou sous SharePoint point de salut sans Forms Server 2007 (et donc licence CAL Enterprise de MOSS/Office)

Bref, ce sont quelques détails, mais je me les prends tout le temps dans la figure par les anciens adeptes de Notes

Fabrice

# avril 6, 2008 02:17

ElVins a dit :

Post intéressant, nous vivons cette phase depuis quelques mois et encore pour quelques années.

La migration Notes->Sharepoint/Exchange est une réalité mais engendre des coûts relativement impressionnants pour obtenir un résultat fonctionnel équivalent. A cause de ces coûts la migration a été reportée et des POCs sont développés en interne pour valider l'intérêt de cette plateforme.

Notre principale problématique est de pouvoir migrer un portefeuille d'applications Notes et de devoir arrêter les demandes d'améliorations de certaines de ces applications.

Pour une grande entreprise l'enjeu et les coûts sont réellement importants!

Je ne te cache pas que l'on pousse malgré tout vers cette situation.

# avril 7, 2008 13:36

Enoelroc a dit :

Bonjour,

vous êtes des gurus SharePoint mais pas des gurus Lotus Notes.

Vous n'avez pas suivi non plus son évolution.

Désolé de vous l'apprendre mais Lotus Notes - Domino était la meilleure application client/serveur collaborative avant qu'IBM n'entre dans le jeux et la réduise à néant au niveau stratégique.

Certain c'est pourquoi je me permet de signaler que certains points sont érronés dans le post.

Dans SharePoint ce qui est désagréable c'est que tout est complètement éclaté, ou alors il faut s'acheter des produit tierce, (merci les SSII et MS qui préfèrent certainement cette approche).

-Pas de formulaires "dignes de ce nom" sans infopath

-Pas de workflows sans Visual Studio et là encore même les spécialites ont de la peine à faire de simples workflows industriels.

-Pas de champs multi values "groupables"

-Pas d'autolookup

-Pas de Timer sans VS.

-la largeur et couleur des colonnes dans les vue ne sont pas du tout adaptables sans SD.

-Pas de validation et transformation sur des champs

-Pas de mode offline natif

-Toujours pas de lookup sur d'autres collections.

-Web parts compliqués et maitrisés que par peux de personnes dans le monde. Même les dévelopeurs .Net doivent impérativement faire valider leur web part pour ne pas avoir de mauvaises surprises.

Résultat final, les coûts et la maintenance devront être à chaque fois être revus à la hausse.

... liste trop longue

Pour en revenir à la migration Lotus Notes vers SharePoint il est vrai qu'une appli Lotus Notes ne peut pas être migrée facilement sous MOSS et encore moins sous SharePoint et surtout pas vite fait. Il vaut mieux vaut refaire faire une appli .Net à la place ou à moins de disposer de l'argent et se payer MOSS, SQL server, Office Ultimate, Visual Studio et SharePoint Designer et surtout une solide équipe de développeurs expérientés. Sinon gare aux mauvaises surprises.

Néanmois étant que donné que Lotus Notes est mort ... vive SharePoint et MOSS qui atteindra certaiement sa maturité dans qqes versions si rien de meilleur n'arrives entre temps.

Meilleures salutations

# avril 7, 2008 13:53

EROLMVP a dit :

Bonjour Enoelroc,

Il y a un marché pour chaque solution, le client lui est l'arbitre, connaissez-vous les parts de marché des solutions ?

Vous indiquez :"vous êtes des gurus SharePoint mais pas des gurus Lotus Notes. Vous n'avez pas suivi non plus son évolution. Désolé de vous l'apprendre mais Lotus Notes - Domino était la meilleure application client/serveur collaborative avant qu'IBM n'entre dans le jeux et la réduise à néant au niveau stratégique. Certain c'est pourquoi je me permet de signaler que certains points sont érronés dans le post."

J'ai personnellement testé LOTUS, effectivement il y a de bonnes choses... Mais le marché demande plus, et MOSS avec Exchange répondent parfaitement à cette demande.

Cdlt

--

P. Erol GIRAUDY

Président du Club MOSS 2007 et MUG.

Vice-Président Club UGO2007

http://clubmoss2007.org

www.mugfrance.fr

# juin 7, 2008 09:30
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01